Re: Kernel SCM saga..

Roman Zippel
2005-04-09T01:00:52Z

Hi,

On Fri, 8 Apr 2005, Tupshin Harper wrote:

> > A1 -> A2 -> A3 -> B1 -> B2
> >
> > This results in a simpler repository, which is more scalable and which is
> > easier for users to work with (e.g. binary bug search).
> > The disadvantage would be it will cause more minor conflicts, when changes
> > are pulled back into the original tree, but which should be easily
> > resolvable most of the time.
> >
> Both darcs and arch (and arch's siblings) have ways of maintaining the
> complete history but speeding up operations.

Please show me how you would do a binary search with arch.

I don't really like the arch model, it's far too restrictive and it's
jumping through hoops to get to an acceptable speed.
What I expect from a SCM is that it maintains both a version index of the
directory structure and a version index of the individual files. Arch
makes it especially painful to extract this data quickly. For the common
cases it throws disk space at the problem and does a lot of caching, but
there are still enough problems (e.g. annotate), which require scanning of
lots of tarballs.

bye, Roman