Re: [Gnu-arch-users] arch lkml

[Roman Zippel]

Hi,

On Mon, 8 Dec 2003, Eric W. Biederman wrote:

> On thing it does not do is have the concept of a distributed repository,
> which may be a strength of bitkeeper.  You may be fine with just very
> good multiple repository handling, but I'm not certain.
>
> I have an odd feel about the way arch does merging and tagging but
> I have not been able to pin down yet if it is a problem or just
> that it does not do things as I would expect.

Actually bk and arch have completely different philosophies and design.
bk is basically a single distributed repository, which records every
single merge, which has advantages when doing repeated merges, you really
only merge what hasn't been merged somewhere else yet. The price you pay
for this (besides the stupid license :) ) is an increased complexity,
where I have my doubts how well it really scales. Simply imagine a number
of active developers, who constantly merge with each other and the number
of merges, which are required to get everything synchronized. To make it
worse not all changes are immediately merged with other developers (only
locally). This means every single normal changeset can cause a large
number of merges, which is extra information that has to managed and
stored.
I think there are few reason the Linux repository hasn't degenerated yet.
First, everything is rather centered around Linus, he does most of the
merges of other repositories and these repositories don't do overly much
merging. Second, a lot is still patch based, which are applied
sequentially and so don't require many merges.
This suggest that bk works best if you merge frequently with short merge
paths to keep the overhead low. Separate development of work which isn't
ready to merge is more difficult, you can rather easily merge other
changes into the working tree, but it's rather hard to extract
independent, reviewable patches.
Arch on the other hand is basically a collection of seperate repositories
and each one a collection of independent patches. Arch doesn't store the
same kind of merge history, which makes merges more difficult, but you
have more control over the merge process.

> The one very obvious potential issue I see with arch as it currently stands
> is that it does not use one of the more sophisticated storage formats
> for storing deltas.  Which means as your archive size increases the work can
> increase.   I think with a different backend format cacherev would not
> be necessary.  But I may be wrong.

I see that problem too, the current format is too much distribution
oriented, where you pay the price in the local handling, e.g. producing
the history of a single file, requires scanning of the whole repository.
The other major problem I have with arch are identifiers, instead of
generating unique identifiers itself, it forces the user to come up with
them. First you have to come up with a rather verbose name for the
repository, instead of just using an arbitrary path from which one can
checkout (as e.g. cvs or bk do). Then it's prefered to generate some
identifiers for your files. If arch generated these identifiers itself
switching between different tagging methods, simply add or remove
something like "$ArchId$" which is expanded during checkout. Arch really
has some usability issues here, only because one can get used to it,
doesn't necessarily make it a good thing.
I'd really like to see a SCM which combines the capabilities of arch and
bk - frequent, easy merging in working repositories, exchange of
independent patches between separate repositories, but I don't really see
an easy way how this could be integrated into the arch design.

bye, Roman