RE: Newby : moving/renaming files loses version information?

[Greg A. Woods]

[ On Wednesday, May 16, 2001 at 09:13:04 (-0500), Thornley, David wrote: ]
> Subject: RE: Newby : moving/renaming files loses version information?
>
> Since it is generally advised to ignore the version numbers and keep
> track of things with tags, this is not usually a problem.  It is possible
> to do "cvs commit -r <new version number>", but that usually doesn't buy
> you anything.

(and of course if you accidentally clash with a magic branch number
you'll cause problems too!  :-)

> This keeps the history [[....]]

Note that there's no history lost with the "remove/add" scheme.  All the
original history is still there, and the original file's ",v" file
remains in the repository (though usually of course it is moved into an
"Attic" sub-directory, but that's just a transparent repo optimisation).

You can access the original history by simply using "cvs log oldname" in
any valid working directory for the same module.

In fact if it's done carefully there's actually more history maintained
than in the "repository copy" scheme!  You can record in the death and
birth comments any information relevant to the rename!  Done poorly even
the "repo copy" scheme actually hides this information!

> Every way of renaming a file in CVS has awkwardnesses or inconveniences.

I find nothing whatsoever "awkward" about the remove/add scheme.  It
works perfectly as far as I can tell.  The awkwardness is in breaking
any pre-concieved and incorrect notions users might have about what a
rename operation actually is.  Even in the unix filesystem a rename is
an add and a delete (though modern kenels can combine both operations in
one system call so that from user-land the operation is atomic and thus
can be used securely for various sensitive tasks such as locking without
mkdir or (O_CREAT|O_EXCL), etc.).  Also if you go look at most any real
database you'll find that you can't rename a key.  You always have to
delete the old key and add a new one.

Anyone who thinks that "cvs log newname" should show the history of the
old file too is sadly mistaken since that's what "cvs log newname
oldname" is intended to do.  If you want both histories in the same
report without having to type both names then it is relatively trivial
to write a little wrapper script that'll do the rename and log
operations in such a way that everything's automatic (using, for
example, magic comments in the death and birth commits that point
forwards and backwards to the old and new names).

The only thing that can get "awkward" is when a file is removed
(eg. when it's renamed, but even when it is only just remmove) and then
a new file matching the old one is added sometime later.  Then a "cvs
log" will show both the ancient history and the new history and it's
pretty hard to notice the "dead" revision sometimes.  My previous
suggestion to help make this better was to stop the "log" whenever a
"dead" revision is encountered (unless some new "I want to see it all
regardless" option is enabled).  [The really awkward part is when the
new file has no related purpose whatsoever to the old file, though at
least then the break in the log is often easier to spot!]

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>