Re: [Twisted-Python] version control, QA, branching ...
"Donovan" == Donovan Baarda <abo@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? Laura
On Sat, Sep 14, 2002 at 04:45:45PM +0200, Laura Creighton wrote:
> "Donovan" == Donovan Baarda <abo@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
participants (2)
-
Anders Qvist -
Laura Creighton