# The form data below was edited by swarm-user
# Perforce Workshop Jobs
#
# Job: The job name. 'new' generates a sequenced job number.
# Status: Job status; [open/closed/suspended]. Required
# Project: The project this job is for. Required.
# Severity: [A/B/C] (A is highest) Required.
# ReportedBy The user who created the job. Can be changed.
# ReportedDate: The date the job was created. Automatic.
# ModifiedBy: The user who last modified this job. Automatic.
# ModifiedDate: The date this job was last modified. Automatic.
# OwnedBy: The owner, responsible for doing the job. Optional.
# Description: Description of the job. Required.
# DevNotes: Developer's comments. Optional.
# Type: Type of job; [Bug/Feature]. Required.
Job: job000145
Status: closed
Project: perforce-software-p4convert
Severity: B
ReportedBy: norman_morse
ReportedDate: 2015/02/05 17:06:40
ModifiedBy: swarm-user
ModifiedDate: 2015/03/10 00:30:37
Description:
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.
DevNotes:
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