Re: [Gnu-arch-users] programming in the large (Re: On configs and huge source trees)

[James Blackwell]

On Tue, Oct 18, 2005 at 11:07:35AM -0700, Thomas Lord wrote:
> Arch is designed for "programming in the large" -- dealing
> with very, very large collections of source.  Ludovic's
> comments are an occasion to refresh people's memory about
> that.

Yeah. I also do not agree with Ludovic that there is a problem with large
trees. Though inventory scanning can get pretty expensive on large trees,
its arguably a feature because of the things brought to the table -- like
automatic linting.

At least directly. Indirectly, there's a helluva problem because large
trees tend to have a lot of history. And that's a blocker for arch
adoption.  Definitely, though, the problem is not tree size, but history
size.  History quickly grows out of proportion in long lived active
branches, achiving histority-to-code ratios of 100:1 (or worse).  By
comparison, I've seen ratios of 5:1 in bazaar-ng and 3.2:1 (!!) in
mercurial. This came at a cost of transparent storage and robustness.

Though the config concept is a solid one, there's a bit of a concept
problem with commit on multi-branch trees.

The rest of your post, save the end, looks good to me.

> It's politically tricky (not impossible, I think) to get upstreams to
> adopt coherent distributed revision control practices and improved
> configure/build/install conventions.   Tools designed with those needs
> in mind are part of the solution.  Obtaining or simulating a critical
> mass of upstream projects that use such tools might do the trick.

Fighting a war on two fronts rarely succeeds. I'd break these into two
mutually beneficial, but independant efforts. That way you don't loose
people on the rcs just because they hate the build system (or, for that
matter, the reverse)

> In any event there's the Arch 2.0 direction, gathering dust on a shelf.
> No matter how many times Matthieu calls it a "complete rewrite" that
> doesn't make it true.  *`revc'* is, indeed, a completely newly coded
> storage manager.   It does replace one part of Arch but not the rest.
> It can do things like give git-like speed for commits and filename-based
> tree comparisons.  It rests for want of resources to port inventory and
> merging features from tla.

Heh. I like to call things that look like roses, that smell like roses,
that feel like roses, roses. There's nothing wrong with a complete rewrite
for arch. 

If the original goal was to prove that decentralized revision control was
possible, then you've succeeded well past your wildest dreams. Though SVN
continues to win on project counts, I believe their adoption has probably
been cut to a third of what it would have otherwise been. Anyways,
userbase isn't the right metric to look at; a better one is mindshare of
developers.  I think obligatory centralized storage is already dead -- the
body just doesn't know it yet.