Re: Understanding move merge

On 20 January 2003, Lele Gaifax said:
 As it stands, given the bugs Karl mentioned, they have the same
 behaviour from the user point of view, but at least with SVN it's not
 a manual tricky hack inside the repository, and neither a dark
 combination of command line options.

To clarify, here's how I rename a file with CVS. Say I'm in ~/project,
the CVS repository dir is $CVSROOT/project, and I want to rename 'old.c'
to 'new.c'.

  cd $CVSROOT/project
  cp -p old.c,v new.c,v
  cd ~/project
  cvs up
  for tag in mumble ; do
    cvs tag -d $tag new.c
  done
  rm old.c ; cvs rm old.c
  cvs ci -f -mRename old.c to new.c. old.c new.c

mumble is some shell magic that gets the list of all tags present in
new.c. This is the step I often forget, but it's important!

Advantages:

  * I can view the log of old.c up to the point of the rename with cvs
    log old.c, at any point in the future. The name old.c lives on
    forever to CVS, but the file no longer exists. Apparently
    Subversion will never be able to do this, because it requires
    guessing the URL for old.c.

  * When viewing the history of new.c, I will see its entire history up
    to, including, and after the rename. Subversion can do this.

  * I can use cvs diff to get diffs from before the rename, or even
    across the rename. Subversion cannot do this, but I gather this
    is a bug that will be fixed.

  * Since I can diff before/across/after the rename, I *assume*
    merging (cvs up -j) works, but I haven't tried it and I very
    rarely merge with CVS. But I know it doesn't work with Subversion.

  * If I check out my project using a pre-rename tag, I will get
    old.c and not new.c. If I check out my project using a post-rename
    tag, I will get new.c and not old.c. (Of course, this only holds
    if I remember to remove tags from new.c, which is why that's an
    important step.)

  * I understand exactly what's going on in the above snippet, and
    so do lots of other heavy CVS users out there

Disadvantages:

  * complicated, error-prone, easy to forget steps

  * not atomic: if anyone checks in changes to foo.c while I'm doing
    my rename, one of us will get ticked off at the other.

  * requires direct repository access

When I say file rename currently works better with CVS than it does with
Subversion, I'm really talking about how things look after the rename
has been done. Once the complicated, error-prone, non-atomic, direct
repository fiddling is done, file renames Just Work with CVS. That's
not currently the case with Subversion.

        Greg

-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org