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

Re: merge tracking in TortoiseSVN

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-06-25 18:43:25 CEST

This is a small update:

On 6/24/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> 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.

After some more thinking about this I have to admit that this is not
possible. To get the information of each *line* where a merge
occurred, we would have to rewrite the whole blame algorithm which is
now done by the Subversion library.
But I think the blame command itself will get some improvements with
merge tracking in Subversion before 1.5 - let's wait until the new API
is in place and decide then.

> 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.

Filed an issue about this here:
http://issues.tortoisesvn.net/index.php?do=details&task_id=369

> 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.

filed an issue about this here:
http://issues.tortoisesvn.net/index.php?do=details&task_id=370

> 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?

and here:
http://issues.tortoisesvn.net/index.php?do=details&task_id=371

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 Mon Jun 25 18:43:04 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.