# 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!