Problem with cvs update -r... -D...

[Renny Barrett]

Dear CVS experts,

 

I'm running into a problem running cvs update with BOTH the options -r
<branch name> and -D <date>.  At best the behaviour I'm seeing is
unintuitive (at least to me!) and at worst I've uncovered a bug.  I'd
greatly appreciate any thoughts or comments you might have or any light you
can shed on the matter.

 

Here's a description of how to recreate the behaviour I'm seeing, together
with comments on what I'm trying to achieve.

 

Let's say that I have a (large) code base, and one day I release my product
to a customer.  Recognising that I may have to supply patches to the
customer whilst also working on the next version, I create a "Patch" branch:

 

cvs rtag -b Patch <MyModule>

 

At some stage later, a developer working on the HEAD creates and commits a
new file:

cvs update -A

cvs add new.txt

cvs commit new.txt

 

At some stage later again, a developer working on the Patch branch creates
and commits a new files which has the same name and location as that created
above:

cvs update -r Patch

cvs add new.txt

cvs commit new.txt

 

So there are 3 time periods in the history of new.txt which I'll refer to
below:

-          TP1 - the time up until new.txt was committed to the HEAD (i.e.
during TP1 new.txt existed neither on the HEAD nor the Patch branch)

-          TP2 - the time from when new.txt was committed to the HEAD but
before it was committed to the Patch branch (i.e. during TP2 new.txt existed
on the HEAD but not on the Patch branch)

-          TP3 - the time from when new.txt was committed to the Patch
branch (i.e. during TP3 new.txt existed both on the HEAD and the Patch
branch, possibly with different contents).

 

Now, a developer requires a new branch off the Patch branch as it was during
a particular time (T) during TP2.  Had we tagged the files on the Patch
branch at T then all would be fine and dandy - we'd simply create a new
branch based on this tag.  However, we neglected to create such a tag so we
need to download the contents of our Patch branch as it was at time T and
then we can use cvs tag to tag these downloaded versions and away we go.

 

To get the contents of the Patch branch as it was at time T, I'm attempting
to use 

cvs update -r Patch -D<T>

.which is where I'm running into problems.  Before I describe what I'm
seeing, I'll explain some other commands which I've tried which do seem to
work the way I'd expect:

 

-          cvs update -D <a time during TP1> - file is deleted from local
directory ("new.txt is no longer in the repository") - this is correct as
the file didn't exist on the HEAD during TP1

-          cvs update -D <T, which is during TP2> - I get the file which was
committed to the HEAD, which is correct

-          cvs update -D < a time during TP3>  - I get the file which was
committed to the HEAD, which is correct

 

-          cvs update -r Patch -D <a time during TP1> - file is deleted from
local directory ("new.txt is no longer in the repository") - this is correct
as the file didn't exist on the Patch branch during TP1

-          cvs update -r Patch -D <a time during TP3> - I get the file which
was committed to the Patch branch, which is correct

 

and finally, the problem one:

 

-          cvs update -r Patch -D <T, which is during TP2> - I EXPECT to
have the local file deleted ("new.txt is no longer in the repository"),
because at time T new.txt did not exist on the Patch branch - what I
ACTUALLY get is the version of new.txt which existed on the HEAD at time T.

 

Thus I don't seem to be able to reliably recreate the contents of Patch at
time T - well, not using cvs update -r. -D. anyway - is there some other
command or option combination that I should use?  I see that cvs update has
a "-f" option which forces a HEAD revision match if the rag/date isn't found
- it's almost as if -f option is kicking in without me specifying it.

 

We're using CVS 1.11.1.1 on Windows talking to a Linux server using
:pserver:; however, I can recreate the same problem on my Windows machine
with  cvs 1.12.9 using :local:.

 

Any help or observations will be gratefully received!

 

Many thanks,

 

Renny Barrett

-