On Sun, Nov 20, 2005 at 01:12:00AM -0800, Andy Tai wrote: > Well, Arch 1 may always suck in some way in this regard... I remember people > complaining about the need to manually specify the use of the revision > libraries... and every 50th > is just a heuristic. Anyway, maybe after the next release we may then adapt > the baz behavior, > with the number of 50 as default but adjustable, and then we can further > explore if even better > algorithms can be applied on top of the Arch 1.x archive formats... > > Based on my understanding, I am afraid performance on large trees will be a > continuous headache > for tla... why, say, tla was not a good choice for the Linux kernel...
I have never heard of anybody getting decent performance for true revision control on a tree the size of linux, and frankly I doubt it's possible. Their solution was git, which is feature-crippled and hugely wasteful of bandwidth and disk space and doesn't attempt to implement revision control. One of the original ideas behind arch was to let you pick your own tradeoffs on a per-project basis. That's the reason for revision libraries as they currently stand. git introduced a new *kind* of tradeoff - bandwidth and disk space for retrival speed; revc was supposed to incorporate this concept into arch. So with that said, it's now possible to answer this one: > > One thing that have frustrate lots of newbies (including me) is the fact > > that to get reasonably > > good performance in any realistic sized tree, you have to have a revision > > library. So why do we > > just enforce this policy in the software so nobody accidentally say arch > > sucks? Because it is fundamentally impossible, from basic principles, to correctly determine the right tradeoffs to make in software. That would require true DWIM and a moderate amount of future-predicting. Arch is designed to let the user make them instead. Running without a revision library in reasonably sized trees *is* viable for a variety of uses. Automatically using them would slow these down and waste disk space in large quantities. The trick is to simplify the mechanisms for making the tradeoffs, not to pretend other users don't exist. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
signature.asc
Description: Digital signature
_______________________________________________ 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/
