Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since version 1.5.0 released in summer of 2008 Subversion does support merge-tracking. Subversion keeps information on performed merges as <em>svn:mergeinfo</em> property set on merge target, be it a branch directory, like <em>^/trunk/</em>, or any other directory.</p> <p>There are major differences between merge-tracking mechanisms in Git and Subversion:</p> <ol> <li><p>The whole branch merge.</p> <p>When you're on <em>master</em> branch, the command</p> <pre><code>$ git merge some-branch </code></pre> <p>results in a merge commit with its first parent set to the commit referenced by <em>master</em> and the second parent set to the commit referenced by <em>some-branch</em> (I don't take into account fast-forward and conflicted merges here).</p> <p>For git it means that created merge commit includes <strong>the whole history</strong> of both <em>master</em> and <em>some-branch</em>.</p> <p>When you've checked out <em>^/trunk/</em> branch into svn working copy and then run</p> <pre><code>$ svn merge ^/branches/some-branch trunk-working-copy </code></pre> <p>Subversion will set <em>svn:mergeinfo</em> property on trunk-working-copy directory as follows:</p> <pre><code>/branches/some-branch:10-20,30-40,50-60 </code></pre> <p>The range <em>10-20,30-40,50-60</em> includes those revisions which are not yet merged into <em>^/trunk/</em> branch from <em>^/branches/some-branch/</em> (Subversion detects them automatically).</p> <p>Mergeinfo property just specifies those revisions which were once merged into the branch. And it's up to user to check whether all these merged revisions include <strong>the whole history</strong> of the branch.</p></li> <li><p>Cherry-pick merge.</p> <p>When you need to merge changes from a single commit into your <em>master</em> branch, you run</p> <pre><code>$ git cherry-pick bc347a8 </code></pre> <p>After that git creates a commit with corresponding changes and a single parent set to the commit previously referenced by <em>master</em> branch.</p> <p>That is, git doesn't create any kind of merge commit for cherry-pick. So, git has no means to track cherry-picked commits via its graph structure.</p> <p>Opposite to that Subversion does track cherry-pick merges by adjusting <em>svn:mergeinfo</em> property with respect to cherry-picked revision:</p> <pre><code>$ svn merge -c100 ^/branches/some-branch trunk-working-copy </code></pre> <p>This command is quite straight-forward, it adjusts <em>svn:mergeinfo</em> as follows:</p> <pre><code>/branches/some-branch:100 </code></pre> <p>That means Subversion tracks cherry-pick merges.</p></li> </ol> <p>So, you don't get merge commits after the translation. To my best knowledge git-svn has certain problems when it comes to merge history. </p> <p>But as subgit developer I have to say that subgit should correctly handle the merge-tracking info. Most probably <em>svn:mergeinfo</em> property set on your branches doesn't include <strong>the whole history</strong> of the branches merged to them. Here's how that could happen:</p> <ul> <li>You have used old svn client (&lt; 1.5), so your branches don't have enough merge-tracking information.</li> <li>You have performed cherry-picks and skipped some revision ranges from adding into <em>svn:mergeinfo</em>.</li> <li>You have <em>svn:mergeinfo</em> set on directories which are not branch directories, i.e. they are not <em>^/trunk/</em>, <em>^/branches/some-branch</em>, etc (for standard layout).</li> </ul> <p>To fix that you have to find the skipped part of merge-tracking information and add it into your branches:</p> <ol> <li><p>Try to find which revision are not yet merged:</p> <pre><code>$ svn mergeinfo --show-revs eligible ^/branches/some-branch/@HEAD ^/trunk/@HEAD </code></pre> <p>The output must include all the revision you haven't yet merged from <em>^/branches/some-branch/</em> to <em>^/trunk/</em>.</p></li> <li><p>Try to merge not yet merged revisions by svn.</p> <ul> <li>If you think all changes are already merged, use --record-only option of svn merge command;</li> <li>If you're not so sure, it's better to perform normal svn merge which will apply all the missing changes.</li> </ul></li> <li>Using subgit you can also merge by git means and then push created merge commits to subgit powered repository, so it will translate these merge commits to svn revisions with correct svn:mergeinfo.</li> </ol> <p>As a nice bonus you may refer to <a href="http://subgit.com/documentation/spec/merge.pdf" rel="nofollow">SubGit specification</a> related to the merge-tracking stuff, it has some pretty diagrams for all I've said above.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload