Tom> Arch is designed for "programming in the large" -- dealing with Tom> very, very large collections of source. Ludovic's comments are Tom> an occasion to refresh people's memory about that.
James> Yeah. I also do not agree with Ludovic that there is a James> problem with large trees. Though inventory scanning can get James> pretty expensive on large trees, its arguably a feature James> because of the things brought to the table -- like automatic James> linting. James> At least directly. Indirectly, there's a helluva problem James> because large trees tend to have a lot of history. And that's James> a blocker for arch adoption. Definitely, though, the problem James> is not tree size, but history size. <cough-cough>revc storage model</cough-cough>. James> If the original goal was to prove that decentralized revision James> control was possible, then you've succeeded well past your James> wildest dreams. Though SVN continues to win on project James> counts, I believe their adoption has probably been cut to a James> third of what it would have otherwise been. Anyways, userbase James> isn't the right metric to look at; a better one is mindshare James> of developers. I think obligatory centralized storage is James> already dead -- the body just doesn't know it yet. So, a bunch of folks including but not limited to Mark should get together, pool some betting money proportionate to my appropriate needs, give it to me, and pose the question "So what have you done ... lately?" And then we'll all live happily ever after. -t _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
