From: David Abrahams (dave_at_[hidden])
Date: 2005-02-04 10:15:27
Rene Rivera <grafik.list_at_[hidden]> writes:
> 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.
Your reports below are certainly worrisome
> 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.
There are various filter programs for post-processing SVN log output,
but I haven't looked at or used any of them, and frankly don't know if
any address this issue.
seems to indicate that the SVN people think it was worth trading that
capability away to gain some others. Now that I think of it, I've
never wanted to see every branch that a file is part of. Tracing back
through a single branch is usually all I'm interested in.
There is a tool called svnmerge that, if we used it for merging,
should make it possible to look backwards through merge points as
well. Or so I think.
> 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.
Seriously?? I've never heard that before, but if so, that's just
dumb. It's not as though the CVS algorithm isn't open source!
> Often resulting in larger conflicts than CVS.
> 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.
Hmm. I'm getting nervous.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk