I hope not to say a lot of bullshit ( :duck!: ), because I'm quite new to the world of gnu arch, so feel free to slash back: I'm just trying to understand, not to flame. Be patient :-)
Thomas Lord ha scritto: > On Sun, 2005-07-10 at 17:45 +0400, nick wrote: > > >> [...] > > Crudely put, the main answer as to why revc is more space hungry is > that, at the scales of use cases of greatest interest, nobody is > (sanely) keeping score about this difference in space consumption. > > I'll say it differently: a modern revision control system can and > probably should gleefully consume local disk space at rates 10x..1000x > greater than, for example, CVS if, in return for doing so, user benefits > can be realized. This is usually fine for a centralized SCM like git. But how about normal users that have not-so-much disk space on their desktop, and want to sync to, say, kernel sources often? I don't want to go out to buy a new hard disk every once in a while to work on a project, even if storage nowadays doesn't cost much. This is also a problem of git, afaik. In contrast, as a "desktop" user, I've a lot of broadwidth to waste, since broadband costs are just a monthly forfait for me (just to say that this scenario is different from the one explained in "How Arch Works"). revc, as tla, would be distributed, and you're likely to have a lot of local branches and revisions. I _liked_ small archives; I liked the way you could mirror them on a USB key, for example, or regularly backup them on cd, the whole of them. It isn't also true that using changesets necessarily hungers for more bandwidth. I don't care waiting a little longer for a repository to be fetched and the changesets applied from the last cached revision; it happens only when doing the first "checkout" (using a CVS word). Then this means less bandwidth usage to get further patches: say that I don't need just a specific revision, but I need to inspect all the differences between a series of them? I need all the patches. And this is often the case, since in many projects you want to be sure that no patch goes in without a review, so you "replay" them one by one. I think that a possible solution to reduce tla bandwidth consumption is a "server" that applies changesets locally before sending a revision through network. And, at the same time, this is exactly what tla is trying to avoid. :-) Hence the revision libraries, and cached revisions, if I understood that correctly. These are obviously my own opinions. I also feel that because git is in use by kernel developers, it doesn't automatically makes that "in" and everything else "out". revc should get better and innovative, not just another between a forest of doujinshi. After all, kernel developers are unlikely to switch off from git at this point of development, so they're not a "target" (using market-speak). In the end, I chose tla over cvs and sv and git because that gives me those "user benefits" you're speaking about. Decentralized development, some (but contained) space consumption in exchange of relative speed, easeness in applying and exchanging changesets between developers, nice merge features and (believe it or not) a nice, if complex at times, user interface. > > Even at that stepped-up rate of space consumption, the cost-of-operation > of a modern system will still be less than the relative cost for > operating CVS in it's heyday. That's for sure. It's hard to make something perform worse than cvs. Please don't take the nag as an example to show how much your horse is good. ;-) > > tla revision libraries are a good hint that this analysis is right: > afaict, plenty of users like me have revlibs that just grow and grow > and include essentially every revision i've got archived or mirrored. > Revision libraries cost more per revision than revc commits yet provide > pretty much the same benefit. And it is good because users at this point can choose not to use them if they don't want to. Can't we continue to strife towards that wonderful "the-user-can-always-choose-what-he-wants" philosophy? Or maybe (probably) it's me that don't understand at all about revision libraries; I simply don't regard them as so important. The documentation is a little bit foggy about them, can someone elaborate on their importance? Cached revisions worked fine for me up until now. > > Other good hints are monotone and git -- we crossed the line at which > sub-file delta-compression ceases to be important in the common cases > some time ago. > > -t > I wouldn't put the word "end" to it so soon... if history teaches that storage grows almost exponentially, it also says that users ask for more space factorially. Anyway, thanks for your wonderful piece of work. Whatever your direction, you've proven to take the right decision most of times. I'll probably follow, but I'd like to be a little bit more sure that this path is really the Zen about SCM. Regards, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? ------END GEEK CODE BLOCK------
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
