# The form data below was edited by robert_cowham # 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. Job: job000065 Status: closed Project: perforce-software-p4transfer Severity: B ReportedBy: tom_tyler ReportedDate: 2014/09/12 12:28:21 ModifiedBy: robert_cowham ModifiedDate: 2014/10/06 10:35:39 Description: P4Transfer stuck on a merge with conflicts. My scenario was that I was merging one entire depot (the "//p4admin" depot) from a large customer server into a fresh, empty, stand-alone Perforce server instance that had only an empty //p4admin depot, waiting to receive the history of //p4admin from the customer’s server. When doing a P4Transfer, it got stuck at one point on a merged file with a conflict, which required manual resolution in the target server. So the submit had failed. I didn't have time to investigate and was not allowed to email outbound. So to work around the problem, I just performed the resolve manually in the target server. Then I restarted P4Transfer, and it went along its merry way and completed the job. (I may have also manually bumped up the counter; I can’t recall for sure). It occurred to me that conflicts requiring resolves shouldn't happen when using P4Transfer, since it knows the historic result of the complex merge resolution in the source server. The desired behavior would be to reproduce the original merge as it was originally done, with the original result, and accurately marked as a merge with edit. The servers were 2014.1, and had dm.integ.engine=3. DevNotes: I cannot recall all the details and don’t have access to the original environment where I encountered this. Apologies if I am missing details ... 2014/10/05 Robert_cowham: I believe this is probably fixed by attached changelists. In the absence of a detailed repro this is now closed!