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

Re: Problem tracking merges with retroactive branch

From: Stefan Hett <stefan_at_egosoft.com>
Date: Fri, 24 Jun 2016 16:13:23 +0200

On 6/22/2016 7:46 PM, Stefan Küng wrote:
> On 22.06.2016 16:43, Stefan Hett wrote:
>> Forgot the attachment...
>> On 6/22/2016 2:58 PM, Stefan Hett wrote:
>>> Hi Ben,
>>> On 6/20/2016 11:36 PM, Benjamin Taylor wrote:
>>>> I have a branch "Foo" where source code for a derivative product (derived from the "Bar" product in the trunk) are tracked. Foo Version 5 was being developed, then stopped while new features and bug fixes for Foo Version 6 were added. I now want to create a branch for Foo Version 5 off a revision before Foo Version 6 feature commits were made, so I can merge just the bug fixes. When I create the FooV5 branch and bring up the revision log for Foo from the merge dialog, it shows no revisions unless I uncheck stop on copy/rename. When I uncheck, all revisions are grayed out as if they were merged, even though they have not been. I can select a revision and merge it, and all works as it should, but all revisions before the FooV5 branch commit are considered merged. Revisions after the branch are not grayed out.
>>>> I did find there were some files in sub directories with merge info in their properties - could this be the source of the problem, and is there a way to fix? Or is there some other way I should be doing this?
>>>> I thought I had used this process before without problems.
>>>> Thanks - Ben
>>> Interesting... I can reproduce the issue here with TSVN 1.9.4 here.
>>> Attached is the demo repository. Steps to repro:
>>> 1. Check out the repository
>>> 2. right click on Branches/Foov5 -> Merge
>>> 3. Select Branches/Foo as the URL and select Show log.
>>> I see the effect Ben describes here:
>>> I would also expect that revision 5 is showing a a possible merge
>>> target (instead I see the empty list).
>>> This is the svn mergeinfo output I'm getting:
>>> E:\[delete]testwc\branches\Foov5>svn mergeinfo
>>> file:///E:/[delete]testrepo/branches/Foo
>>> youngest common ancestor
>>> | last full merge
>>> | | tip of branch
>>> | | | repository path
>>> 4 6
>>> | |
>>> -------| |------------ branches/Foo
>>> \
>>> \
>>> --| |------------ branches/Foov5
>>> |
>>> WC
>>> If I'm reading this right, then this looks correct to me.
>>> Doing a merge via the command line:
>>> svn merge file:///E:/[delete]testrepo/branches/Foo_at_5
>>> merges the revision correctly.
> With TSVN, you have to specify the revisions-to-merge not just as "5"
> but as "5_at_5" - much the same as with the CL client where you specify the
> peg revision in the URL.
> You need the peg revision because the branch was not created from HEAD,
> so the default peg revision HEAD won't work here.
In the following I'm fully talking from a plain user's experience point
of view. I'm not questioning the technical correctness of TSVN/SVN here
(which I understand and agree is absolutely correct within the current

To explain the use-case I'm talking about:
1. Do a checkout of the test repository I attached.
2. Right click on wc/branches/Foov5 -> TortoiseSVN -> Merge
3. Next
4. URL to merge from select branches/Foo
5. click on Show Log

Note that the "Stop on copy/rename" is ticked.

Actual result:
The list doesn't display anything.

Expected result:
The list should display revision 5, since the branch was created from
revision 4.

Foov5 was created from revision 4 (not revision 5) from branches/Foo -
therefore Stop on copy/rename should stop at revision 4 (aka: exclude
revision 4) but not revision 5.

Wouldn't you agree that this behavior would be more user friendly and be
what a user would expect to see in this case?

Stefan Hett
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-06-24 16:13:35 CEST

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