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

[Echlin, Michael]

Hi,

The cp oldname-newname suggestion below is my preferred solution as it still
allows use of the old file when checking out an version of the software
prior to the renaming. (This happens way to often for my liking but when you
inherit someone else's headaches...)

If the tags are proper and you start with an empty work directory (so that
new files added are not included in the old checkout) this works very well
and it always includes all of the history when you get a QA audit. Bob, boo,
hiss, hiss :-b
     
Mike

-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: May 16, 2001 8:43 AM
To: Hondros, Constantine
Cc: 'address@hidden'
Subject: Re: Newby : moving/renaming files loses version information?


"Hondros, Constantine" <address@hidden> writes:

> Does moving / renaming a file in CVS necessarily mean that the "new" file
> ends up at version 1.1?

If you do it in the way you describe (which is the only way that I
know about to do it without directly frobbing the repository) then
yes.

> I followed the instructions at the (excellent) red-bean CVS tutorial
thusly
> :
> 
> floss$ mv oldname newname
> floss$ cvs remove oldname
> floss$ cvs add newname
> floss$ cvs ci -m "renamed oldname to newname" oldname newname
> 
> and found that the "newname" file started at version 1.1. 
> 
> Is this situation avoidable?

Yes, if you're willing to move things around in the repository itself,
and if you're willing for the resulting file to show up in the old
location when you do a checkout based on an old date or tag. Just do this:

1) in the repository, do "cp oldname,v newname,v"
2) in a work directory, do "rm oldname; cvs remove oldname; cvs commit"
3) Still in the work directory, do "cvs update" to get a working copy of
newname.

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs