I'm assuming you meant me.
I'm not *that* well-versed with the RCS file format. I do know, though, that
anyone can figure it out just by looking at it and intelligently changing some
things (after making a backup of course).
The way I'd attack this problem would be to:
1. add a new file
2. copy the archive
3. remove the file
4. diff the archive against the previous one
This'll tell you exactly what CVS did to remove the file (aside from putting the
archive in the Attic). This should arm you with enough info to backtrack from
the bad remove. Again MAKE BACKUPS BEFORE ANYTHING ELSE. Also, make sure
*noone* else is doing anything to these files.
You might also want to see if "cvs admin" can help you in this situation -- I
know it can physically remove revisions from the archive, but it may not remove
the effects of those revisions.
Sorry I can't help more than this.
Noel
[EMAIL PROTECTED] on 05/21/2000 11:08:22 PM
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Re: Bug (?) in branching support / removed files
I am looking for help from someone who knows the RCS file
format quite well. Noel, this probably means you :-)
About a week ago, I had a problem.
In summary, I made changes to a working directory, including
deleting files; I then tried to commit to a branch.
Unfortunately, the deleted files were deleted from the
trunk, not from the branch.
(side note: 'Trunk' is actually the vendor branch in this
case.)
> 1. Make changes to the local copy, including deleting files.
> 2. Decide that you want to commit to a branch, not the trunk.
> 3. 'cvs tag' will not work, nor will 'cvs tag -b' as there are errors to
correct
> first.
>
> 4. 'cvs rtag' will assign both the base-tag and the branch tag.
> 5. At this point, I did not want to do 'cvs update -r newBranch', as a plain
> update would refetch all the files that I have deleted. So, I first do a 'cvs
> rm' on the deleted files. I'm told to do a commit to force them to go away.
>
> 6. 'cvs update -r newBranch' to switch to the branch.
> 7. 'cvs commit' to make my commit on the branch.
>
> EXCEPT:
> The deleted files are deleted FROM THE TRUNK, NOT FROM THE BRANCH.
Now I'm trying to recover from this.
> Here's a log output of one of the deleted files.
> $ cvs log GADBEc.h
>
> RCS file: /lab/CVS/GABackend/GABase/GADBBase/Attic/GADBEc.h,v
> Working file: GADBEc.h
> head: 1.2
> branch:
> locks: strict
> access list:
> symbolic names:
> twoGADBBase-StillNotWorking: 1.1.1.1.0.2
> base-twoGADBBase-StillNotWorking: 1.1.1.1
> initial: 1.1.1.1
> michael: 1.1.1
> keyword substitution: kv
> total revisions: 3; selected revisions: 3
> description:
> ----------------------------
> revision 1.2
> date: 2000/05/16 06:54:44; author: michael; state: dead; lines: +0 -0
> To try to solve the linking problem on NT, GADBBase was split into two parts.
It
> did not help -- the linking problem is still present. Neither of the two are
> seen, although other pieces are seen.
> ----------------------------
> revision 1.1
> date: 2000/05/10 18:07:20; author: michael; state: Exp;
> branches: 1.1.1;
> Initial revision
> ----------------------------
> revision 1.1.1.1
> date: 2000/05/10 18:07:20; author: michael; state: Exp; lines: +0 -0
> All the backend (models, support code) is here.
> =============================================================================
> $
>
> The file needs to be alive in 1.1 / 1.1.1.1, and dead in 1.1.1.1.0.2.
> It should have no state in 1.2 at all.
And this last point is the key. If the changes that I'm
making (which I'm putting on a branch) don't work, I don't
want any sign of these tests in the main system. I want
those files alive.
I don't know the ins and outs of RCS file formats. My
current thought/plan is to edit all the files in the attic,
change the RCS line that identifies the 'dead' state, and
then put them back into the non-attic storage section.
Is this kosher? Will this work? Are there any pitfalls that
I don't know of that will kill me?
Michael
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
