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. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
