[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: checkout with -D resurrects deleted files
From: |
Eric Siegerman |
Subject: |
Re: checkout with -D resurrects deleted files |
Date: |
Thu, 19 Apr 2001 19:27:38 -0400 |
User-agent: |
Mutt/1.2.5i |
On Thu, Apr 19, 2001 at 03:11:46PM -0500, Bruce Tiffany wrote:
> I believe I've found the source of my confusion. When a file is deleted
> in
> CVS, then revised by another user, cvs checkout will not produce the file,
> however cvs checkout -D <now> will. I'm uncertain if that's a bug or a
> feature, use of checkout -D ... seems to be the safer way to go.
Looks like a bug to me. Tested with CVS 1.11, all actions
performed on the trunk:
> Time User 1 User 2
> ---- -------------------- ------------------------------
>
> | cvs checkout proj1 cvs checkout proj1
> | rm foo
> | cvs -remove foo
> \|/ cvs commit
Does what you'd expect -- checks in a "dead" revision and moves
the ,v file to the attic.
> edit foo
Note that a "cvs commit" here correctly reports "Up-to-date check
failed for `foo'".
> cvs update
Says:
$ cvs update
cvs update: Updating .
RCS file: /home/erics/t2/Repos/p/Attic/foo,v
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into foo
foo already contains the differences between 1.1 and 1.2
$
Shouldn't it have reported a conflict?
> cvs commit
Commits User 2's text as a new undead revision (ie. state="Exp"),
but DOES NOT move the ,v file back out of the Attic, thus
violating this constraint, as documented in the manual, node
"Attic":
[...] the rule is that the RCS file is stored in the
attic if and only if the head revision on the trunk has
state `dead'.
The reported inconsistency between "cvs checkout" and
"cvs checkout -D now" follows from this.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)