[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

merge tracking in TortoiseSVN

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-06-24 14:14:00 CEST

Hi,

As promised before, here's my suggestion on how and where to use the new
merge tracking information of the Subversion 1.5 library. Please feel
free to make suggestions and comments about this.

First, the 'easier' places where the merge information is useful (I
don't want to say 'needed' because up until now, we all got away without
any merge information at all).

Blame:
In TortoiseBlame, we show the log message of every line in a file. But
if such a line got changed because of a merge, and the merge log message
only contains something like "merged rXXXX from /branch/XXXX", then the
*real* log message is lost. The log message of the merge isn't really
useful for blaming.
With the merge tracking information, I'd like to show the real or
original log message too for every line.
I'd like to do this by fetching the svn:merge propety of the blamed file
in HEAD, then simply append the log messages of those merged revisions.
Problem here: merges usually happen from other branches. Currently,
we're fetching the log for that particular file alone. With the merge
information, we also have to fetch the log for that file in the merged
branch to get those log messages too. But with the log cache in place, I
don't think we will have a real problem with performance. Only if the
user has deactivated the log cache then this will of course take a lot
more time until we have all the necessary information.

Commit:
I'm sure if we don't do this, users will soon request this :)
After a merge is done and the user wants to commit the merge, there's
the task to write the log message. We have to provide a way for the user
to insert the log message of the revision(s) he merged.
Since this could take a while to fetch those log messages (ans some of
you may know that I'm completely against contacting the repository from
the commit dialog), I would suggest to catch that information from the
merge dialog itself, i.e., either during or right after the merge
itself. Maybe store the log messages in a temp file which can be used
later in the commit dialog.

Log:
The log dialog is used in several places. Apart from the obvious
'standalone' part, it is also used in other dialogs. For example the
merge dialog to select the revision(s) to merge.
For that, I'd like the log dialog to have some indicator icon on the
left of each log entry showing whether that particular revision has
already been merged or not.
This can be done by getting the svn:merge property of the HEAD revision,
parse the content to get a list of the merged revisions. Not a big
performance hit, so I think we can live with that just fine.

Revision graph:
It would be nice (in some cases) to show 'merge lines' in the graph,
i.e., a line from one revision to another indicating that the revision
got merged. Of course, this isn't really useful for already big graphs
because if we add merge connection lines, the graph will get even bigger
and of course also more cluttered.
This could be done too by reading the svn:merge property and get the
list of merged revisions. But to get all the information we need, we'd
have to read the property for *all* top nodes, which can be a lot.
Here, caching the information would definitely help, but I'm not sure if
that's really possible. After all, we would need the property from HEAD
for each node.
However if we want to show *all* merges, even those which happened for
individual files below e.g., trunk where the graph is shown for, this
would take *hours* (not joking here!), so I won't implement something
like this.
Or maybe we should create a completely separate merge graph?

Apart from those places, I don't see any more where we could use the
merge info (to get some benefit from).

This information here is only on how we use the merge *info*.
There's other work we have to do to implement merge tracking. For
example the conflict handling during a merge. But that's something I'll
implement myself once Subversion has all the API's ready and somewhat
stable so I don't have to rewrite everything should they decide that the
API isn't good and change it.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jun 24 14:13:54 2007

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.