[Bese-devel] Why we use arch [Was: the archives (the ucw development branch is MOVING!)]

[Marco Baringer]

On Sabato, mar 6, 2004, at 00:03 Europe/Rome, Jan Rychter wrote:

> It has certainly been very confusing for me. Do you find it
> significantly better than, say, subversion? (I guess the simple CVS is
> out of fashion these days)

[CVS is not just out of fashion, CVS would be a bad engineering choice 
for new projects.]

Here's why, just under a year ago, I started using arch and have since 
stuck with it:

0) If you ever want to take ucw and modify it you can, completely 
independantly, branch from the ucw tree, selectvly update from the 
"official" ucw repo and easly send your patches back to me.

You do not need commit rights on the main tree to develop UCW, you just 
need to tell we which patch to merge in, i do a 'tla replay 
ucw at rychter.com/ucw--cool-featureX--0.2--patch-3' and commit, this 
works, automatically resolves most conflicts when you, for example, 
updated with the main dev branch half way through your changes, and 
maintians all associated logs.

1) When I started using arch subversion did not have a stable release, 
maybe is was just FUD but the "grapevine" said to wait for 1.0

2) Arch works in terms of changesets, which contain a single log 
message, a globally (yes globally) unique id and all associated changes 
(renames, moves, adds, deletes and modifications). I find this to be a 
much better match to how I think than subversion's "every modification 
to the file system is a single, independent, change". Now, I could 
build something like this on top of subversion, and i'm sure someone 
has, but why do the extra work?

3) Arch knows which changesets have gone into a tree, this means that 
if i'm working on the yaclml--use-xmls--0.4 branch and i get a patch 
for yaclml--dev--0.4 i can apply that to the dev branch, merge that 
into the use-xmls branch and then, when i'm done with the use-xmls 
branch and want to merge it back into the dev branch arch knows that 
patch has already been applied. This makes branching and merging much 
more manageable. Subversion plans on addidng these merging features but 
hasn't yet.

4) Arch uses a dumb-server. While subversion requires a WebDAV server i 
was able to setup the arch repos on cl.net by simply creating a 
directory in my public_htdocs tree, at the same time all commits are 
done via ssh, subversion would have required much more work on erik's 
part.

5) Very recently arch has gained the ability to gpg sign all patches, 
while this isn't essential it does make me feel better.

At the same time arch does have its quirks:

1) It imposes the weird category--branch--version--patch-level syntax.

2) Arch doesn't have the concept of a "root" repository, which is 
confusing.

3) When you update a tree you only get the patches in that revision, so 
if you have ucw--dev--0.1 and i strat working on ucw--dev--0.2 you 
won't get the patches from 0.2 unless you explicitly do a tla replay 
ucw--dev--0.2 and then tla set-tree-version ucw--dev--0.2.

4) Arch doesn't provide support for "symbolic" tags, and the configs 
are something of a joke.

5) arch can, at first, seem overwhelming with it's 100+ commands.

so, i think arch is better than subversion, is arch better "enough" to 
make the added confusion worth it? i don't know.

--
Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen