Re: address@hidden: Re: rename in cvs]

[Kaz Kylheku]

In article <address@hidden>, Dave Storrs wrote:
>Hi Miklos,
>
>       What he means is this:  let's say that you want to rename file
>"foo.c" in your working copy to "bar.c", and you want the name change to
>sync up in the repository, without losing any of "foo.c"'s version
>history.  You would then do the following:
>
>- Make sure no one else is accessing the repository right now.

The way you do that is by creating a lock directory.

>- 'cd' into the repository, find the file named "foo.c,v"
>- 'mv foo.c,v bar.c,v'

Before you do anything, "mkdir #cvs.lock". If that fails, wait and
try again.

Note that Karl Fogel already provided the advice of cp'ing the
file. This is more sensible because it produces a new object without
destructively manipulating the old. So foo.c,v is still there with
its version history intact; you merely have a duplicate.

The best way is to do this from the working copy. Copy your working
foo.c to bar.c.  Then do:

        cvs add bar.c
        rm foo.c
        cvs rm

and commit. In other words, cvs remove the old, add the new.

>       I've done this and it works, as long as no one is doing a checkout
>or update while you are renaming (if they are, results are undefined
>(=="openly hostile", as K&R once remarked)).

You could have found out on how to place a lock with a tiny amount of RTFM.

>       The only downside is that you will not be able to reconstruct the
>project as it did before you did this rename...because CVS will not be
>able to serve up the file "foo.c" file for you.

And after that downside, you think there is still an upside?
Version control has gone out the window basically. Bye bye tagged,
reproducible builds.

There are other downsides, like people's working copies having dangling
references to a nonexistent version file. People may have local
modifications to the renamed file.