On Wed, 2005-10-19 at 17:06 +0200, Paolo Carlini wrote: > Daniel Berlin wrote: > > >5. Lastly, just to be clear, if you guys don't think the benefits > >outweigh the costs, we don't have to move. > >So far, the amount of dissent i've heard is pretty small, but please, if > >you don't want to move (or you do), please speak up, instead of silently > >suffering (or silently being in joy). > > > > > Thanks Danny for asking. I'm reading the various messages coming to the list > and, well, I'm *worried* the benefits will *not* outweigh the costs for many > of us. > > Sorry for the harsh and naive question: *which* are the benefits for people > *not* managing many branches? No, it's a perfectly fair question.
For people not managing any branches, your main advantage is changesets, local operations for diff/add/delete/move/etc, renaming files, and everything is atomic. This means no more waiting for locks, even during commits. The only time it will complain at you is if someone has touched the exact path you are trying to commit since you last updated. If you want to pull or apply patches, or reghunt, you can do it by revision number, instead of tring to figure out what files made up a patch. You just ask it for "the diff that produced revision 12312 from revision 12311" and that includes *the entire diff*, not just the changes for a single file. Scripts are easier to produce, since anything you can do from the command line, you can do with the bindings, very easily.. However, this is also true of *any* newer revision control system from CVS. They all share the "disadvantages" of subversion (global revision numbers, carrying around more data, etc). In fact, AFAIK, none of them actually let you work entirely disconnected without carrying repo history (IE they won't go fetch things remotely in any automatic way), in a way that a no-pristine copy subversion should. So i guess the first decision is "do we want to stay with cvs forever, or move to something different that has some advantages and some disadvantages for most people, and very large advantages for some people." This *really* is the main decision. The rest is just timing. I'm not trying to force anything on anyone. If we truly want to stay with CVS forever, let's do that. But you should know that it's a pain in the ass for people trying to manage branches of any sort, do any sort of renames, and who don't want to wait 30 minutes to commit things while people tag. We just don't complain about those things because we had to live with them for so long, we are used to this. Also, considering we keep telling people to put changes and features on branches, it is somewhat disingenuous to make that hard. This is part of the reason people send large patches at the beginning of stage1 that nobody has ever seen. Nobody wants to maintain a branch for something small. Now, personally, i'm confident the disk space issue (both mirroring the remote repo, and working copy size) will go away in a newer version of subversion, most likely 1.4 (unless disaster strikes, that's where the patch i'm working on should end up). svnserve is getting ssl and SASL support, which should be in 1.4, and we would be able to use that in place of SVN+SSH, which should provide stuff without the overhead of SSH. However, there will always be issues, no matter when we move. There is always something better down the pipe that will fix issues. The longer you wait, the bigger your initial repos are going to be. In february, the converted repo was 6 gig :) cvs2svn is very good at what it does, but it has a very tough life trying to convert file revisions into changesets, and make single revision branches and tags out of mashed potatoes. As for other VCS'en, Subversion has the advantage that i know how to fix the issues we have, and will do so personally, if nobody else does. This of course, will take time, but i can make that promise because i'm a subversion committer, and i know how to get things into subversion releases. --Dan