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