Re: A couple more subversion notes

[Daniel Berlin <dberlin at dberlin dot org>]

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