You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Olof <ol...@baah.se> on 2016/07/02 07:18:58 UTC

Visualize when two branches have been merged

Hi

The only feature I'm really missing with SVN is the ability show in
revision graphs when two branches have been merged. This applies to both
the command line client and Tortoise. This feature is quite common in
version management and is very useful so why doesn't SVN have it? I've
googled some and found this
http://stackoverflow.com/questions/918638/tortoisesvn-revision-graph-merge-line-connected-back-to-trunk
discussion. However I don't agree with the most popular answer (SVN can't
guarantee that such a visualization would show the truth since commits are
done in working copies). To me a line in revision graph showing when two
branches are merged would be just a visual representation of the already
existing svn:mergeinfo. I can select to "show merged versions" in the log -
isn't that just a textual representation of the graph I looking for?

// Olof Wolgast

Re: Visualize when two branches have been merged

Posted by Andreas Krey <a....@gmx.de>.
On Sat, 02 Jul 2016 13:52:05 +0000, Stefan Sperling wrote:
...
> And I agree that this argument is missing the point. It claims that because
> a merge may select just a subset of changes committed in a particular revision,
> drawing a "line" to indicate a merge commit would be misleading since not
> all changes from the revision were merged.
> But that is the case for every version control system since merge commits
> are never a 1:1 mapping of changes, e.g. due to conflict resolution.

I'd still say that these are two different things (not merging the
entire tree but only selected files vs. dropping changes in the
actual merges).

In the first cases there is no mergeinfo for the files that are
not merged, and drawing a global merge arrow is arguably wrong.

But in the other case I do record the merge info even
if I then drop a merged-in change, essentially saying
"yes, I dropped this on purpose, and don't bring it
in again in the next merge". And the recorded mergeinfo
for the entire tree should be displayed as a merge info.

> The misconception seems to be that a conceptual 'merge arrow' implied
> a 1:1 mapping of changes, but it does not.

The fun thing is that a a merge is a symmetric operation with
respect to the contents, so if you don't draw the merge arrow
(second parent in git parlance) on that argument, you shouldn't
draw the straight line from the previous to the merge revision
('first parent') either. (Just as you can drop merged-in changes
in a merge conflict resolution you can as well drop changes
from the straight line.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Visualize when two branches have been merged

Posted by Stefan Sperling <st...@elego.de>.
On Sat, Jul 02, 2016 at 09:18:58AM +0200, Olof wrote:
> Hi
> 
> The only feature I'm really missing with SVN is the ability show in
> revision graphs when two branches have been merged. This applies to both
> the command line client and Tortoise. This feature is quite common in
> version management and is very useful so why doesn't SVN have it? I've
> googled some and found this
> http://stackoverflow.com/questions/918638/tortoisesvn-revision-graph-merge-line-connected-back-to-trunk
> discussion. However I don't agree with the most popular answer (SVN can't
> guarantee that such a visualization would show the truth since commits are
> done in working copies).

I suppose you meant to say "merges are done in working copies".

And I agree that this argument is missing the point. It claims that because
a merge may select just a subset of changes committed in a particular revision,
drawing a "line" to indicate a merge commit would be misleading since not
all changes from the revision were merged.
But that is the case for every version control system since merge commits
are never a 1:1 mapping of changes, e.g. due to conflict resolution.
The misconception seems to be that a conceptual 'merge arrow' implied
a 1:1 mapping of changes, but it does not.

> To me a line in revision graph showing when two
> branches are merged would be just a visual representation of the already
> existing svn:mergeinfo. I can select to "show merged versions" in the log -
> isn't that just a textual representation of the graph I looking for?
> 
> // Olof Wolgast

Yes, it should be possible to implement such a feature.
Would you like to work on this? We'll need someone in a position to have
a need for this feature and the time and skills to make it happen.
I would support this effort if such a person showed up.

The svn mergeinfo command already shows a graph based on mergeinfo. But that's
not the information display you're looking for, assuming you're looking for an
equivalent to a holistic view similar to 'git log --graph', while the mergeinfo
command shows information about the relative state of just two branches:

$ svn mergeinfo ^/subversion/branches/authzperf
    youngest common ancestor
    |         last full merge
    |         |        tip of branch
    |         |        |         repository path

    1613052            1751050 
    |                  |       
       --| |------------         subversion/branches/authzperf
      /         /              
     /         /               
  -------| |------------         subversion/trunk
              |        |       
              1714639  WC      
$