Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Friday, February 22, 2002 at 14:45:32 (-0600), Steve Greenland wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> On Fri, Feb 22, 2002 at 02:14:21PM -0500, Greg A. Woods wrote:
>> > [ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: 
>> > ]

>> Since I can read the history of a single file
>> (non-renamed) with one cvs command, I wanted to know how to do it when
>> the file (entity, if you prefer) *had* been renamed, or moved to another
>> directory. Reading the change log of the current file to (hopefully)
>> find the comment about what the name of the file *used* to be and then
>> reading its changelog, etc. etc. is *not* hardly more difficult.

>It seems perfectly simple and very quick when I do it.  Perhaps you
>should try it:

>       cvs log newfile.c | less

>       [[ read along until you get to the end and see: - moved
>       oldfile.c to newfile.c]]

>       cvs log oldfile.c | less

>       [[ and so on.... ]] 

There's just one little problem with this:  "cvs log" only works when
a file is in your sandbox.  If it's been removed and committed, then
you must do something like "cvs rlog `cat CVS/Repository`/oldfile.c | less".

But that only works if the file was renamed in the same directory, not
if it was moved to another directory.  In this latter case, you need to
know where in the repository the RCS file sits, and that info isn't
usually available without some effort, particularly if the module isn't
defined trivially in the modules database.  (Typically checking out the
module with an old tag is needed, and even then it won't always work if the
module was changed in the modules database.)

Actually, there's a second problem, too:  Simply listing the log gives
unwanted history if one of the file's paths was reused (i.e. one of the
RCS files contains partial histories of multiple "entities").

Of course in the general case, one would not assume that the file has
been renamed only once...

>> The
>> only place the rename info is stored is in the changelog, and if the
>> person who made the change didn't get the right comment in there, it's
>> lost. Should the comment be there? Of course. But people make mistakes.

>So automate the process with a wrapper that doesn't make mistakes!!!!!!

>Said wrapper is already quoted below!

>>      cp $1 $2
>>      cvs rm -f $1
>>      cvs add $2
>>      cvs commit -m "moved $1 to $2" $1 $2

>Yup, that's pretty much it.  It sure is easy isn't it!  You need some
>more mechanism around it if you want to use it as a general wrapper
>(i.e. to enforce its usage), and of course there are the other bits that
>should be self obvious if you want "log" and "diff" and such to work
>across renames.  Such a feature could trivially be built into the many
>front-ends too (which are usually literally "wrappers"), such as PCL-CVS
>(which is the one I use), or WinCVS, etc.

That wrapper does not record all of the necessary info.  Nor can it,
because in the common case the RCS file of the target is unknown
until the commit completes.

This exercise also doesn't consider the implications of doing the "cvs add"
part in a sandbox that has been updated with a different branch than the
original file.

For now I'll ignore simple bullet-proofing issues, like preventing the user
from renaming a file to one that already exists...

>--- End of forwarded message from address@hidden