Andrew Goktepe wrote:
Thanks, that did help. I was able to re-remove the file after removing
the HEAD sticky tag. My update script was blindly specifying the tag
for each project, which seems to be what got me into this mess.
But is it really normal behavior for an update -r HEAD to bring in
files that have been removed? I've found 3 resurrected files so far.
No, it shouldn't do that.
Here's the sequence of events in case that sheds any light on this:
1) ran a cvs update -r HEAD (mistake to specify HEAD here)
2) created a branch and a tag on the local checkout dir from above
3) noticed in viewcvs that some files on the trunk had a state of
'Exp' and a very old mod date when they should have state 'dead'. It's
like someone restored the files this week but the date on the change
is over a year ago. The previous revision shows the dead state.
Strange, I tried an 'update -r HEAD' and it did not retrieve any dead
revisions, even if I explicitly asked for the dead files.
Could tagging the local checkout with the HEAD sticky tag somehow have
brought back these dead files?
I don't think so. I just tried using both 'rtag' and 'tag', and even
though rtag tagged the dead revision, I still could not retrieve the
dead revision, either by specifying -r HEAD or by specifying the tag
applied to the dead revision.
Do you have access to backups that were made before this problem
surfaced? If so, can you retrieve one of the backups (without
overwriting the current file) and see what its state on the head
revision is?
--
Jim
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/info-cvs
