job000743
Closed
An SVN dump file entry which branches a deleted revision will fail.
Apparently SVN will "copy" the latest, undeleted version of a file to the
new location. Perforce does not undelete it at the head revision, the way svn does.
This causes comparison problems between the files in the SVN repository and the Perforce depot.
Conversion errors show:
22 Feb 2019 17:31:24,968 INFO com.perforce.common.process.ProcessNode ... 10691.2 B:F - branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp (UTF-8)
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp@10670 - all revision(s) already integrated.
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp - file(s) not on client
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/A
Exploring this in the debugger shows that The SVN dump entry for 10691.2 is referencing a deleted revision
of AbstractScreencast.cpp.
Dump is on warp in warp/cases/00369890
030619 - norman_morse Duplicate of job000599 closing...
Apparently SVN will "copy" the latest, undeleted version of a file to the
new location. Perforce does not undelete it at the head revision, the way svn does.
This causes comparison problems between the files in the SVN repository and the Perforce depot.
Conversion errors show:
22 Feb 2019 17:31:24,968 INFO com.perforce.common.process.ProcessNode ... 10691.2 B:F - branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp (UTF-8)
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp@10670 - all revision(s) already integrated.
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp - file(s) not on client
22 Feb 2019 17:31:24,968 WARN com.perforce.common.client.P4Factory ... p4java: //Scopis/branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/A
Exploring this in the debugger shows that The SVN dump entry for 10691.2 is referencing a deleted revision
of AbstractScreencast.cpp.
Dump is on warp in warp/cases/00369890
030619 - norman_morse Duplicate of job000599 closing...
- Status
- Closed
- Project
- perforce-software-p4convert
- Severity
- B
- Reported By
- Norman Morse
- Reported Date
- 6 years ago
- Modified By
- Norman Morse
- Modified Date
- 6 years ago
- Owned By
- norman_morse
- Type
- Bug
Commit 10691 contains the following changes, according to Tortoise SVN:
Deleted: /branches/_experimental/2012 NOVIS Refactoring/NeuroNavigation/Application/IO/AbstractScreencast.cpp
Added: /branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp
as a copy of /trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp@10670
The file names may be the same, but the three paths are mutually different.
I'm not sure what you mean by "referencing a deleted revision". At revision 10691, the history of /trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp says that this file was last changed at revision 10661. At 10670 it is not deleted.
The SVN dump for 10691.2 contains the same info:
Node-path: branches/_experimental/2012 NOVIS Refactoring/NOVIS/Screencast/AbstractScreencast.cpp
Node-kind: file
Node-action: add
Node-copyfrom-rev: 10670
Node-copyfrom-path: trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp
Looking at the converted code in P4V the history of trunk/NeuroNavigation/Application/IO/AbstractScreenCast.cpp shows that the file was deleted in revision 10661
That is why the source file at revision 10670 is deleted. I believe that SVN and P4Convert handle this
case differently, which causes the file diffs you've seen
Oh, I see. Thank you for pointing that out. So the problem was actually in the conversion of 10661. In this commit, /trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp is deleted, and is then added back as a copy of trunk/NeuroNavigation/Application/IO/AbstractScreenCast.cpp@10657.
The problem is that p4convert applies these changes in the wrong order:
28 Feb 2019 18:17:03,989 INFO com.perforce.common.process.ProcessNode ... 10661.3 B:F - trunk/NeuroNavigation/Application/IO/AbstractScreencast.cpp (UTF-8)
28 Feb 2019 18:17:04,820 INFO com.perforce.common.process.ProcessNode ... 10661.22 R:F - trunk/NeuroNavigation/Application/IO/AbstractScreenCast.cpp (UTF-8)
Because it applies the branch/copy first, and the delete later, the result is that the file ends up missing on the Perforce server.
On the plus side, the audit.log does have checksums for the missing files.
Notice how the filename case changed!
What triggered this issue was https://swarm.workshop.perforce.com/projects/perforce-software-p4convert/jobs/job000599
In general P4Convert does not handle case-insensitive file paths/names.
It's true that the case changed (didn't even notice), but I don't think that's what's causing the issue. In SvnProcessChange.processChange(), p4convert processes files in the order they are listed in the dump. Unfortunately, SVN lists the add (copy) record before the delete.
I found a small Python library for reading and writing SVN dumps at https://github.com/zeha/py-svndump I used it to write the attached script. It reads a dump, reorders the records for each revision such that the deletes come before any other node. This fixes the problems in 10661 and 10691. Currently waiting for confirmation on 22199.
I don't understand why this happened on Linux, though.
Well. The change in case might be the reason why the records are in that particular order, though.