Geek Answers Handbook

Are svn idempotents being drilled?

It seems to me that they should be. I assume that you resolved the conflicts that occurred during the first merge operation.

+4
source share
2 answers

From a theoretical point of view, the merger is not idempotent. A true merge (which Subversion supports in a broken way 1 since v1.5 2 ) writes the commit as having two (or more) parents; usually you assume that the resulting tree is a combination of parent commits. However, most (but not all) version control systems note that one of the parents (one of the branches in the merge) is a strict ancestor of the other, and instead of creating a merge, it simply promotes one branch. (Git makes this situation fast or relevant).

After merging, we have the following situation after "scm merge B", when on branch "A" (below there is an attempt on the ASCII-art diagram):

  --- * --- * --- * --- A --- M <--- trunk (branch A) 
                                   /
 --- * --- * --- * --- B- / <--- branch (branch B)

Merge commit "M" has parents "A" and "B". Now re-scm merge B could create the following situation:

  --- * --- * --- * --- A --- M --- N <--- trunk (branch A) 
                                   ///
 --- * --- * --- * --- B - / ---- / <--- branch (branch B)

where merge commit "N" has "M" and "B" is like parents. (In some cases, the Bazaar may create such a situation)

Edited 2007-07-22:

The operation is idempotent if several operation applications do not change the result. Merge will be idempotent if "scm merge branch_B && scm merge branch_B" gives the same result as a single "scm merge branch_B". Some version control systems have idempotent merging; for example, Git will indicate "Already updated" on the second identical merge in the line and not create new commits. Some version control system does not work; if I understand correctly, depending on the parameters specified for the merge command, Bazaar can create a new merge with the parents "M" (previous merge) and "B" (from branch_B) and a tree (content) identical to the merge "M".

Footnotes

  • Client - tracking third-party mergers (if PhilM is wrong)? Merge information should be stored in the repository (in the case of a centralized version control system such as Subversion, this means it is stored on the server).
  • You can use the svnmerge or SVK extension, which is a (semi) distributed version control system built on top of Subversion.
+4
source

If you use Subversion 1.5 or higher, and your svn:mergeinfo are updated correctly, then yes. However, since Subversion uses client-side merge tracking, if the svn:mergeinfo modified to remove / change the merge history, then you will most likely end up in files that are in a state of conflict.

+3
source

More articles:


All Articles