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

RE: Suggestions for Merge Dialog

From: Damian Powell <damian_at_shadow-angel.com>
Date: Fri, 4 Jan 2008 11:16:01 -0000

> > When 'Merge a range of revisions' is selected:
> >
> > 1. It would be helpful if the 'URL to merge from' field would default to
> > the location that this branch was copied from.
> We could do that, yes. But:
> 1) this information can only be obtained if the server supports merge
> tracking (otherwise it would take ages to find out)
> 2) even with merge tracking, it would take a few seconds to get that
> information

Isn't this information available in the log cache though? So if it's
available in the cache, you could use it, otherwise do the current

Love the log cache by the way. I use the log and repo browser frequently so
anything that makes the log quicker is a very welcome thing.

> 3) it already defaults to the last used URL. That means once you've
> entered that url yourself, the next time you do a merge it will already
> default to that url.

It's a little confusing though. If I merge from trunk into my WC which is a
branch from the trunk, I probably want the merge from URL to be
svn://myserver/repo/trunk which is fine. However, if I subsequently want to
merge the changes from a sub directory of the trunk into the equivalent
subdir on the branch, the merge from URL is the last used URL
(svn://myserver/repo/trunk) which isn't what I want. I want
svn://myserver/repo/trunk/subdir in this case.

Now I know that this is simple to change but it's also easy to not notice
and for users who aren't necessarily familiar with branching (aka SourceSafe
users) they might think that it is correct because the /repo/trunk URL is
where the WC comes from.

Would it be possible to remember merge from URL's for each WC directory that
a merge is performed into, rather than for all merges?

A more robust solution could be to add a tsvn:branchedfromurl property when
a branch is created. To find this information when the merge dialog opens,
you only need to scan each of the parent directories of any given item in a

> > 2. It would be helpful if the 'Revision range to merge' field would
> > default to the next revision after the latest revision that was
> > previously merged into this branch, up to HEAD.
> I don't see a real benefit here:
> * without merge tracking, that information is not available

Again, I'm assuming this information is available in the log cache. Please
correct me if I'm wrong.

> * with merge tracking however, you don't need it: simply merge
> everything (i.e., you can leave the revision range field empty).

When I try this, I get the message "Not all required revisions are
specified" which would seem to indicate that I can't leave the revision
range empty.

> > 3. When the 'Show log' button in the 'Revision range to merge' group box
> > is clicked, it would be helpful if there was a visual queue to say which
> > revisions have already been merged into this branch for items under the
> > 'URL to merge from' directory. (#1) (#2)
> There is, but only if the server supports merge tracking.
> > #1: Didn't the log used to do this in earlier nightly builds? I have a
> > vague memory of seeing a whole bunch of grey log entries at some point
> > and I'm sure it was when I was browsing the log to find my last-merged
> > revision.
> It still does.

Cool. Thanks.

> But as mentioned above, only if the server supports merge tracking too.
> If the server doesn't then the required information is not available and
> can't be shown.

Log cache? :)

> > #2: Actually, it would be useful when browsing the log on a branch if
> > there was an obvious visual queue at the point where the branch was
> > created. [snip]
> I'll think of something to indicate this better.

I look forward to it. Thanks again.


To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-01-04 12:27:26 CET

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.