Seems to me like they should be. I'm assuming you've resolved any conflicts that arose during the first merge operation.
+4
A:
If you're using Subversion 1.5 or greater and your svn:mergeinfo properties are being updated correctly, then yes. However, as Subversion uses client-side merge tracking, if the svn:mergeinfo property is modified in such a way to remove/alter the merge history, then you will likely end up with files left in the conflict state.
Phil M
2009-07-21 00:31:08
So, svn depends on remembering that it already did a merge?
allyourcode
2009-07-21 01:32:39
@allyourcode: Yes, this memory is implemented as `svn:mergeinfo` properties. See http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html for lots of details on this.
Greg Hewgill
2009-07-21 02:38:06
+3
A:
From theoretical point of view merge is not idempotent. True merge (which Subversion supports in a broken way1 since v1.52) is recording commit as having two (or more) parents; usually you assume that result tree is combination of parent commits. However most (but not all) version control system notice that one of parents (one of branches in merge) is strict ancestor of the other and instead of creating merge it would just advance one branch. (Git cals this situation fast-forward or up-to-date).
After a merge we have the following situation after "scm merge B" when on branch "A" (below there is attempt at ASCII-art diagram):
---*---*---*---A---M <--- trunk (branch A)
/
---*---*---*---B-/ <--- branch (branch B)
Merge commit "M" has parents "A" and "B". Now repeated "scm merge B" could have created the following situation:
---*---*---*---A---M---N <--- trunk (branch A)
/ /
---*---*---*---B-/----/ <--- branch (branch B)
where merge commit "N" has "M" and "B" commits as parents. (In some cases Bazaar can create such situation)
Edited 22-07-2009:
Operation is idempotent if multiple applications of the operation do not change the result. Merge would be idempotent, if "scm merge branch_B && scm merge branch_B" would give the same result as single "scm merge branch_B". Some version control system have idempotent merge; for example Git would state 'Already up-to-date' on second identical merge in the row, and do not create new commit. Some version control system doesn't; if I understand correctly depending on options given to merge command, Bazaar can create new merge commit with parents "M" (previous merge) and "B" (from branch_B) and tree (contents) identical as merge "M".
Footnotes
- Client-side merge tracking (if PhilM is not correct)? Merge information should be stored in repository (in the case of centralized version control system like Subversion it means storing it on the server)
- You could use svnmerge extension, or SVK which is (semi)distributed version control system built on top of Subversion.
Jakub Narębski
2009-07-21 07:52:22
Thanks for trying to give a more theoretical answer to this question; that's really what I was after :P. Unfortunately, I can't understand much of your answer: 1) I can understand why you'd think svn's merge is inferior (it doesn't have multiple parents), but why do you say svn's merge is not "true merge"? Seems like a perfectly legitimate merge to me.
allyourcode
2009-07-22 03:19:27
2) What is it that most version control systems do when they detect that one rev is the parent of another? Once I figure this out, I think I can understand why git calls it "fast-forward" or "up-to-date"
allyourcode
2009-07-22 03:22:14
@allyourcode: 1.) in Subversion from 1.5 merge commit has multiple parents stored in `svn:mergeinfo` property. It is "true merge" but IMHO not implemented correctly, as I think that information about merge parents should be stored on server not on client. 2.) "up-to-date" (see edit) means that second merge would do nothing in Git. 3.) see added explanation.
Jakub Narębski
2009-07-22 08:31:04