[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tortoisesvn-users
Subject:    Re: Problem tracking merges with retroactive branch
From:       Stefan Hett <stefan () egosoft ! com>
Date:       2016-06-24 14:13:23
Message-ID: b44395f1-7192-220c-789b-5387516e1151 () egosoft ! com
[Download RAW message or body]

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@5
> > > 
> > > merges the revision correctly.
> With TSVN, you have to specify the revisions-to-merge not just as "5"
> but as "5@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 
design).

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.

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

-- 
Regards,
Stefan Hett

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3176658

To unsubscribe from this discussion, e-mail: \
[users-unsubscribe@tortoisesvn.tigris.org].


[prev in list] [next in list] [prev in thread] [next in thread]