jobs/job000145

job000145

norman_morse (Norman Morse)
Norman Morse created this job 10 years ago, modified by swarm-user 10 years ago
Closed
CVS Conversion will sometimes generate bogus file histories with deletes as the first record.

Associated with case 00107916  I will send repro kit to the developer.
12002
12001
Status
Closed
Project
perforce-software-p4convert
Severity
B
Reported By
Norman Morse
Reported Date
10 years ago
Modified By
swarm-user
Modified Date
10 years ago
Dev Notes
Customer Says:

I have found a discrepancy between the CVS repository and the resulting Perforce depot. Hopefully I can get a quick response on this and we can determine how to handle it.

I’m going to assume you still have access to my test CVS repository. This is regarding file “files.f”.

On the “TSMC40LP” branch, I have the following history:

% p4 -p 2001 filelog //depot/icm/proj/USB30phy/TSMC40LP/rtl/rtl/files.f
//depot/icm/proj/USB30phy/TSMC40LP/rtl/rtl/files.f
... #5 change 242549 edit on 2013/04/15 by shg@p4-client (ltext) 'added DW02_mult to files.f '
... #4 change 242543 edit on 2013/04/13 by shg@p4-client (ltext) 'fied the USB2.0 BERT test issu'
... #3 change 242525 edit on 2013/04/07 by shg@p4-client (ltext) ' added all chnage after design '
... #2 change 242519 branch on 2013/04/05 by sharathk@p4-client (ltext) 'fixed the CDC issue '
... ... branch from //depot/icm/proj/USB30phy/main/rtl/rtl/files.f#1,#12
... #1 change 242518 delete on 2013/04/05 by shg@p4-client (ltext) 'file files.f was added on branc'

Notice the first change is a delete. This doesn’t make sense and probably shouldn’t even be listed.

Here is the pertinent data from the CVSdump. Note the dates and the extra delete.

('2013/04/05:20:00:34', 'shg', 'CVSrepo/usb30_phy/rtl/files.f,v', '1.12.2.1')
('2013/04/07:16:48:05', 'shg', 'CVSrepo/usb30_phy/rtl/files.f,v', '1.12.2.2')
('2013/04/13:15:27:46', 'shg', 'CVSrepo/usb30_phy/rtl/files.f,v', '1.12.2.3')
('2013/04/15:18:05:25', 'shg', 'CVSrepo/usb30_phy/rtl/files.f,v', '1.12.2.4')

Customer also says:
Because of how we’re integrating from the new depot to our existing depot (change-by-change, label-by-label) it does cause a problem. Since the first version (the “delete” version) can’t be imported, all subsequent version have an incorrect version number. This throws off labeling since that tries to match version to version across depots.
Type
Bug