job000192
Closed
The problem reported in job000145 still exists.
I can provide a CVS repository which exhibits this behavior.
This seems to stem from not handling the 'dead' state. The CVS history shows:
----------------------------
revision 1.12.2.1
date: 2013/04/05 20:00:34; author: shg; state: dead; lines: +0 -110
file files.f was added on branch TSMC40LP on 2013-04-07 16:48:05 +0000
----------------------------
A quick Google search gives an explanation:
http://osdir.com/ml/version-control.cvs.general/2003-01/msg00060.html
Based on this, the version should simply be ignored - not included in the new Perforce history of the element.
I can provide a CVS repository which exhibits this behavior.
This seems to stem from not handling the 'dead' state. The CVS history shows:
----------------------------
revision 1.12.2.1
date: 2013/04/05 20:00:34; author: shg; state: dead; lines: +0 -110
file files.f was added on branch TSMC40LP on 2013-04-07 16:48:05 +0000
----------------------------
A quick Google search gives an explanation:
http://osdir.com/ml/version-control.cvs.general/2003-01/msg00060.html
Based on this, the version should simply be ignored - not included in the new Perforce history of the element.
- Status
- Closed
- Project
- perforce-software-p4convert
- Severity
- C
- Reported By
- ddvalk
- Reported Date
- 10 years ago
- Modified By
- Perforce maintenance
- Modified Date
- 6 years ago
- Owned By
- ddvalk
- Type
- Bug
If you have a single RCS file or a small data set that demonstrates the issue, please email me at pallen@perforce.com
Please detail how you would expect the history to look in Perforce (e.g. annotated
p4 filelog)Email sent with an example file. As I wrote initially, I think the CVS version should simply be ignored and shouldn't be reflected in the Perforce history.
Thank you, I have your email. Interesting comparison between 1.13.2.1 and 1.12.2.1.
As you say it would seem that 1.12.2.1 should be ignored and 1.12.2.2 the first ADD on that path. Where as 1.13.2.1 would be a BRANCH from 1.13.
Why wouldn't 1.12.2.2 also be BRANCH since the branch wouldn't have existed before that? Perhaps this is just semantics and the effect would be the same.
If the revision containing the (dead) branch has been ignored, when it come to process the subsequent revision there is no earlier history tying it back.
Do you know the sequence of CVS command to get into this state?
Unfortunately, no. I tried to recreate it but couldn't get the exact behavior. Here are the steps I tried:
mkdir /tmp/cvsroot
export CVSROOT=/tmp/cvsroot
mkdir /tmp/cvstest
cd /tmp/cvstest
cvs init
cvs checkout
cvs tag TMPLABEL
cvs tag -r TMPLABEL -b newbranch
cvs update -r newbranch
echo just testing > trouble.c
cvs add trouble.c
cvs ci -r newbranch trouble.c
cvs log trouble.c