Re: [Gnu-arch-users] arch lkml

[Miles Bader]

On Mon, Dec 08, 2003 at 10:25:24AM -0700, 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.

What do you mean?  Please distinguish between the two.

[FWIW, I do think that arch's use of a single global namespace tends to give
it the feeling of a single huge repository split into many pieces.]

> 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.

Hard to comment on that, obviously.

Some of arch's attributes are rather _different_ from traditional SCSs,
which often causes a bit of discomfort among newbies (particularly the
tagging style, namespace issues, etc), but it's also often the case that
these feelings soon subside.

> 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.

Please give details.

Arch's archive (repository) format is actually very good for a certain set of
operations, and less good for others -- and this is true of every repository
format.  The question is whether the things it's good at are the right things
or not (for instance, it's extremely efficient for doing commits, and for
doing incremental updates).

One thing _is_ clear: the current representation is a _huge_ win if
something goes wrong, because it doesn't use a big-binary-blob (or multiple
smaller-binary-blobs) every storage, everything is in clear common formats.

-Miles
-- 
"1971 pickup truck; will trade for guns"