[Twisted-Python] version control, QA, branching ...

[Anders Qvist]

On Sat, Sep 14, 2002 at 04:45:45PM +0200, Laura Creighton wrote:
> > >>>>> "Donovan" == Donovan Baarda <abo at minkirri.apana.org.au> writes:
> > 
> > yeah -- my original take on arch was that its implementation made it
> > unacceptable. but as i think about it, i'm not sure that's such a big
> > deal; the design seems sound from the docs, and since it's written in
> > a "software tools" style, incremental conversion to Python should be
> > feasible if that's ever desired. So... it's tempting to try for some
> > less-important repositories, i think. (TRDemo, perhaps?) The "FTP" and
> > "shell" aspects of it are pretty nonessential to its operation, so far
> > as i can tell.
> 
> Anders, you're already started with this, correct?  How far along 
> did you get?

No, I tried to port it to various architectures.

Arch has two fundamental flaws in its implementation. Any conversion
of arch should address those flaws.

1) Output even more difficult to parse than cvs.
2) There is no server part. Since each user runs the software that
   modifies the repository, there is a significant risk that different
   versions will misunderstand some other version's actions. In other
   words: every version of arch must be tested together with all
   others. Upgrading arch means that you must force _all_ users to
   upgrade.

I think the best thing would be to create a central python module
which exports functions. When you want to drop one of arch's shell
scripts, you change larch to call a function in that module.

In that module, you abstract all interaction with the repository, so
that when the time comes, you can easily create an arch server simply
by converting the abstraction into <insert favourite RPC mechanism
here> and forward the calls to the machine holding the repository.

Along the same lines, you make the various functions in the arch
module return its results as relevant Python data types and have larch
do the translation into human readable data. If larch is called with
--machine-readable, it just outputs string representations of the
return data types, which should be easy enough to parse (esp if you
are a python program!).

-- 
Anders "Quest" Qvist

"We've all heard that a million monkeys banging on a million typewriters
will eventually reproduce the entire works of Shakespeare. Now, thanks 
to the Internet, we know this is not true." -- Robert Wilensky