Paul Hammant's Blog: Subversion Merge Limitations That Are Not In Perforce
Fourth in a series of blog entries related to a Subversion merge problem, I thought I’d try Perforce in the same scenario. Note that is the traditional client/server Perforce rather than the newer DVCS or Git interop modes of operation.
Here’s Subversion blowing up in a merge scenario after a series of cherry-picks, when it shouldn’t have done, from the first blog entry:
Attempt redundant merge of branch two into branch one (individual commits are merged already, and files at HEAD revision are idential):
--- Merging r2 through r13 into 'one':
C one/testfile.txt
--- Recording mergeinfo for merge of r2 through r13 into 'one':
U one
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'one/testfile.txt'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
(mc) my side of conflict, (tc) their side of conflict,
(s) show all options:
So here are the same bash scripts, but issuing Perforce commands rather than subversion ones (link to Github repo/branch).
And the diff between the the Subversion base version, and the perforce version might prove interesting to some (as github presents that).
The same two tests again…
Repeating the tests yourself
I rely on a second repo, for some Perforce setup script. Check that one to an adjacent directory to the test scripts:
git clone git@github.com:paul-hammant/fast_perforce_setup.git
git clone git@github.com:paul-hammant/subversion_testing.git
cd subversion_testing
git checkout p4_equivalent
Test one - cherry-picking one way - all good
./reset.sh
./server.sh
./test_of_out_order_merges_from_one_branch_to_another.sh
Merging changes out of order from branch ‘one’ to ‘two’ worked fine. Script:
test_of_out_order_merges_from_one_branch_to_another.sh
Here’s the end of that script’s output:
Locking 1 files ...
integrate //depot/two/testfile.txt#6
Change 13 submitted.
File(s) up-to-date.
Changes Perforce thinks are unmerged, after merge of all the individual commits (out of order)
//depot/one/... - all revision(s) already integrated.
Performing a non cherry-pick merge (should be redundant)...
//depot/one/... - all revision(s) already integrated.
two/testfile.txt - no file(s) to resolve.
.... as indicated by 'No files to submit':
No files to submit from the default changelist.
Unlike Subversion, Git and Mercurial, after a series of seemingly complete (if out of order) cherry-picks, Perforce does not want to do one more ghost merge. It was happy with the constituent cherry picks.
Test two - cherry-picking back - all good too
Do the first script (actually the sequence of three commands) before the key one for the second test. You may have just run them, of course, so skip them below and so command #4:
./reset.sh
./server.sh
./test_of_out_order_merges_from_one_branch_to_another.sh
./test_of_out_order_merges_back_the_original_branch.sh
For subversion, this one had a bug in it - or rather highlighted a bug in Subversion. Mercurial Script:
test_of_out_order_merges_back_the_original_branch.sh
This was merging another series of changes, as cherry-picks, back to ‘one’ from branch ‘two’. As Git and Mercurial, it worked without barfing, unlike the Subversion one (see previous blog entry). As for the first Perforce script there’s no ghost merge in this sequence. The result (last lines only):
Change 23 submitted.
File(s) up-to-date.
Changes Perforce thinks are unmerged, after merge of all the individual commits (out of order)
//depot/two/... - all revision(s) already integrated.
Performing a non cherry-pick merge (should be redundant)...
//depot/two/... - all revision(s) already integrated.
one/testfile.txt - no file(s) to resolve.
.... as indicated by 'No files to submit':
No files to submit from the default changelist.
As expected, nothing to merge. Let's try another redundant combo - from 'one' to 'two':
//depot/one/... - all revision(s) already integrated.
two/testfile.txt - no file(s) to resolve.
Again, as indicated by 'No files to submit', there was nothing to merge.
Notes
I wish Perforce’s command line was a little more terse. For example, p4 integrate has to be followed by p4 resolve to do the actual text merge before the commit. It would be nice if that were an option in the first like so: p4 integrate --automerge to be more like the other tools.