Re: [Sbcl-devel] svn

[<bdo...@la...>]

Sorry, this is getting a bit off-topic for sbcl-devel...

On Sat, May 05, 2007 at 11:14:12AM +0200, Peter Herth wrote:
> > My biggest beef with SVN is, frankly, the branching model.  Simulating
> > branched history by copies screams "mind-numbingly wrong!" to me in so
> > many ways---even to the point where I find I prefer the (also hideous)
> > branching of CVS to it.
> 
> I would be interested in which way this seems wrong to you?

History in revision control is not linear -- fundamentally, it's a
graph.  (Whether it be a graph of actual revisions or a graph of patch
dependencies a la darcs.)  svn only supports tracking a linear revision
history, and kludges branches on the side via a lightweight copy
mechanism.

But this completely breaks the way I expect branching to work.  When I
branch, I am creating a fork in history, not copying the tree I am
working with!

It just feels to me like the devs realized they had a lightweight copy
mechanism and could replicate CVS branching behavior with that and some
standard practicess (the branches and tags directories), rather than
actually implementing non-linear history.

(Darcs is a bit different --- darcs doesn't really track history, so
branching in darcs is just a matter of different patch selection.  While
I think darcs is very pleasent to use [until it breaks], I'm not in love
with that part of it.  I would prefer a system that could combine some
of the patch-algebra features of darcs with something that actually
tracked all history; however, those two things may be mutually-exclusive
for all I know.)

> > a) How the heck do I find out what the branch point of a branch is?
> >    Even the stupid CVS trick (tagging the branch point) doesn't help,
> >    because a tag is just another copy.
> 
> svn log --stop-on-copy will list the history of the branch till the
> branching point (where it was copied from e.g. trunk)

This seems to tell me how far back a branch goes, but doesn't tell me
what revision and URL it was branched from.

> > b) Being able to delete a branch makes me queasy.  I understand it's
> >    just deleting it from the current view of history, and it nicely (?)
> >    solves the nasty problem of wanting a branch named "foo" that's
> >    completely different from the branch you had named "foo" three years
> >    ago, but I've not found a nice way to go back and view the branch
> >    with the popular browser tools available without randomly guessing
> >    at which revision it might have existed.
> 
> Looking at the history of the "branches" directory should reveal all
> branching and deleting operations.

Right, and my point was that this seems hard to do with the SVN
browsing interfaces I've used.

> > c) The usual merge stupidities, shared with CVS, except I think CVS
> >    might actually have more information available about the structure of
> >    history.
> 
> What do you mean by "the usual stupidities"?

The lack of automatic merge tracking.  Given the rather free-form nature
of svn's copy operator, I have no idea how you would implement merge
tracking for all copies --- if the svn developers can actually pull it
off, more power to them.

> > d) It seems to me that SVN (or perhaps Tortoise/SVN) makes the operation
> >    of copying a branch to trunk without a merge a little bit too easy.
> >    We've had developers at work kill useful changes without knowing
> >    about it until it turned up weeks later.
> 
> The only things you might be able to really kill are uncommitted
> changes in your workarea. Other than that, all changes are properly
> tracked by svn so you can always revert them in a clean way. So in my
> experience it is rather harder to do permanent damage in svn than in
> cvs.

Obviously I wasn't referring to permanently damaging the repository -
the history is still there.  However, changes were copied to trunk
/without merging/, thereby overwriting other useful changes that had
happened in the interim.  (Not in history, but in current version of
the software that we were compiling, which is just as bad.)

Other systems, especially the distributed ones, make it difficult to
merge a branch without actually merging the changes.  (Conversely,
they make merging easy enough that there's no reason to try to avoid it.)

-bcd