[boost] Re: Was [RE: Moving from CVS to Subversion?] Now is "Subversion experiences from the field"

From: David B. Held (dheld_at_[hidden])
Date: 2005-02-05 04:10:47

Rene Rivera wrote:
> [...]
> My experience with SVN has not been all that pleasant but perhaps it's a 
> result of only using the command line, maybe the GUIs out there fare 
> better.

Perhaps you should try TortoiseSVN.  It's fairly slick and makes
things decently intuitive.  But really, you should try Eclipse.
Unfortunately, the easiest type of project for Eclipse is Java.  But
there's no reason someone couldn't write nice C++ plugins for Eclipse
(and I rather think someone should).  If you could see how Eclipse
integrates with SVN, you would probably agree that most if not all of
your problems go away.

> 1. Obtaining information about the repository without doing a checkout 
> of every branch, tag, etc. is horribly painful. The history/log facility 
> is almost useless. For example I don't think theres way to find out in 
> what branches/tags a particular file revision is part of, other than 
> getting the complete repository and doing a file find.. yuk.

Hmm...not sure why you would need to do this, but I would be curious
to see what they say on the mailing list.  On the other hand, A) most
people who need this information will probably already have the 
repository checked out, right?  B) This doesn't seem like a very
common operation.  Probably not something that the average coder will
need to be doing regularly.  On the other hand, the things that the
average coder will be doing often are mostly done better by SVN (like
2-way diffs, local caching of revisions for fast local history, more
complete tracking of repository changes, like file renames, directory
restructuring, etc.).  As far as using the history for normal type
tasks, it seemed perfectly reasonable to me, and not too dissimilar
from other VCSes.

> 2. Conflict resolution when doing a merge is basically unworkable. Like 
> CVS it decorates the working copy with "<<"/">>" comments, and copies 
> the previous version. But the conflict resolution algorithm it uses 
> makes worse, IMO, choices than the CVS equivalent. Often resulting in 
> larger conflicts than CVS.

I can't speak to conflict resolution by hand.  But in Eclipse, it is
much much easier than the various conflict resolution tools I've used
for CVS.  The different lines of code are connected by a line that
stretches as you scroll the different windows, making it very easy to
spot the changes and see how they fit in the overall structure.
Copying changes one way or the other is just a simple mouse click.  I
really don't see how it could be any simpler without the IDE reading
your mind.

> 3. The lack of in place branching makes many things harder, and the 
> possible equivalent of "svn copy"+"svn switch" is very difficult to 
> manage. This discourages the use of small short lived branches useful 
> for experimental code changes.

Actually, SVN makes it a point that branches are cheap exactly because
they do a shallow copy, and that you should make as many branches as
you like.  It may be difficult to manage from the command line, but
again, I don't know, because branching and switching in Eclipse is both
trivial and utterly painless.  The only trick I had was merging changes
from one branch to another, but that's just because I don't do that
very often, so it's not very intuitive for me.  I haven't tried it from
TortoiseSVN, though, so it might be more complicated there.  It really
is unfortunate that there isn't a good C++ plugin for Eclipse.  You
would wonder how you ever coded without it.

Dave