Or, you could copy the ,v file to the new location and move the original to the Attic. (Well, that's true if the rename is on the trunk. If it's on a branch only, don't move to the Attic.) That at least leaves the original version history in its original location. The downside that, of course, is that checking out with old tags produces the file in two places. But that can be countered by removing the offensive tags from the new copy. Care must be taken with branch tags, however: You'll want some of them to be made "dead" in the original location.
Generally speaking, renaming stuff in CVS is royal pain. You always lose something. It's up to you to decide what you're willing to give up. >--- Forwarded mail from [EMAIL PROTECTED] > 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. >- 'cd' into the repository, find the file named "foo.c,v" >- 'mv foo.c,v bar.c,v' > 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)). > 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. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
