You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Folker Schamel <sc...@spinor.com> on 2004/09/04 13:19:49 UTC
Problem with following renames in 1.1
Hello!
Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
However, when merging changes from trunk into a branch or vice versa
("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
rename tracking seems to fails.
See the transscript below.
The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
I suppose this is a more fundamental problem, but neverthanless:
Are there plans to improve this?
*****
C:\temp\svntest>svnadmin --version
svnadmin, version 1.1.0 (Release Candidate 2)
compiled Aug 13 2004, 15:20:48
Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
C:\temp\svntest>svnadmin create --fs-type fsfs repro
C:\temp\svntest>svn mkdir file:///temp/svntest/repro/trunk -m ""
Committed revision 1.
C:\temp\svntest>svn checkout file:///temp/svntest/repro/trunk wc_trunk
Checked out revision 1.
C:\temp\svntest>echo file1 1>wc_trunk/file1.txt
C:\temp\svntest>echo file2 1>wc_trunk/file2.txt
C:\temp\svntest>echo file3 1>wc_trunk/file3.txt
C:\temp\svntest>svn add wc_trunk/file1.txt
A wc_trunk\file1.txt
C:\temp\svntest>svn add wc_trunk/file2.txt
A wc_trunk\file2.txt
C:\temp\svntest>svn add wc_trunk/file3.txt
A wc_trunk\file3.txt
C:\temp\svntest>svn commit wc_trunk -m ""
Adding wc_trunk\file1.txt
Adding wc_trunk\file2.txt
Adding wc_trunk\file3.txt
Transmitting file data ...
Committed revision 2.
C:\temp\svntest>svn copy file:///temp/svntest/repro/trunk file:///temp/svntest/r
epro/branch -m "Release"
Committed revision 3.
C:\temp\svntest>svn checkout file:///temp/svntest/repro/branch wc_branch
A wc_branch\file2.txt
A wc_branch\file3.txt
A wc_branch\file1.txt
Checked out revision 3.
C:\temp\svntest>svn move wc_trunk/file2.txt wc_trunk/file2_moved_in_trunk.txt
A wc_trunk\file2_moved_in_trunk.txt
D wc_trunk\file2.txt
C:\temp\svntest>svn commit wc_trunk -m "Refactoring"
Deleting wc_trunk\file2.txt
Adding wc_trunk\file2_moved_in_trunk.txt
Committed revision 4.
C:\temp\svntest>svn move wc_branch/file3.txt wc_branch/file3_moved_in_branch.txt
A wc_branch\file3_moved_in_branch.txt
D wc_branch\file3.txt
C:\temp\svntest>svn commit wc_branch -m "Rename in branch"
Deleting wc_branch\file3.txt
Adding wc_branch\file3_moved_in_branch.txt
Committed revision 5.
C:\temp\svntest>echo file1.new.branch (bug fix in branch) 1>wc_branch/file1.txt
C:\temp\svntest>echo file2.new.branch (bug fix in branch) 1>wc_branch/file2.txt
C:\temp\svntest>echo file3.new.branch (bug fix in branch) 1>wc_branch/file3_mov
ed_in_branch.txt
C:\temp\svntest>svn commit wc_branch -m "Bug fixes in branch"
Sending wc_branch\file1.txt
Sending wc_branch\file2.txt
Sending wc_branch\file3_moved_in_branch.txt
Transmitting file data ...
Committed revision 6.
C:\temp\svntest>svn merge file:///temp/svntest/repro/branch -r 5:6 wc_trunk
Skipped missing target: 'wc_trunk\file2.txt'
Skipped missing target: 'wc_trunk\file3_moved_in_branch.txt'
U wc_trunk\file1.txt
C:\temp\svntest>
*****
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Folker Schamel <sc...@spinor.com>.
Greg Hudson wrote:
> A side note: when you start a completely new thread on the dev list,
> please do not do so by replying to a message and changing the subject.
> Doing so causes your message to be incorrectly threaded in mail
> archives.
>
>
>>However, when merging changes from trunk into a branch or vice versa
>>("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"), rename tracking seems to
>>fails.
>
>
> After a careful review, I think Ben's initial reply to your message
> was confused, and everything which follows from it was equally
> confused, including my own response. So, ignore all that stuff. "svn
> merge -rX:Y URL" follows renames when picking the merge anchors just
> like "svn merge -rX:Y WCPATH" follows renames.
>
> The real answer to your question is: once the merge anchors are
> picked, all merging is performed by pathname. This is part of what
> Tom Lord refers to as Subversion's "anemic merge support".
>
>
>>See the transscript below.
>
>
> Now that I review your transcript, I think it fails in exactly the way
> I would expect it to fail.
>
>
>>Merging within one tree ("merge -r X:Y WC-PATH") nicely follows
>>renames in 1.1.
>
>
> You didn't post a transcript of this succeeding. I assume you were
> merging individual files, or merging within a tree whose contents had
> experienced no renames (although the tree itself may have moved
> around).
Yes, my mistake - I only tested with an individual file.
>>Are there plans to improve this?
>
>
> Vague ones. See
> <http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt>,
> point C. The solution to this problem may involve some fairly deep
> changes to the filesystem structure (we have to support "true
> renames"), so it may be a 2.0 improvement.
Yes, I supposed something like that.
We came accross that issue because currently we have a long living branch.
We regulary merge from trunk (having trivial scripts managing
the last merged revision).
And due to refactoring, several files are renamed in the branch.
So we encountered that issue.
[One helpful smaller change may be to not only eject the warning
"Skipped missing target", but set the nearest existing parent directoy
into a merge conflict state.
From the theoretical point of view, "Skipped missing target"
is a merge conflict.
From the pratical point of view, this avoids that you oversee
such merge failures, because svn status does not show again
the "Skipped missing target" warning.]
However, it's definitely no serious issue!
Most merging works absolutely fine. And some tweaking by hand
for these special issues is no problem at all.
Thanks for your explanations!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Greg Hudson <gh...@MIT.EDU>.
A side note: when you start a completely new thread on the dev list,
please do not do so by replying to a message and changing the subject.
Doing so causes your message to be incorrectly threaded in mail
archives.
> However, when merging changes from trunk into a branch or vice versa
> ("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"), rename tracking seems to
> fails.
After a careful review, I think Ben's initial reply to your message
was confused, and everything which follows from it was equally
confused, including my own response. So, ignore all that stuff. "svn
merge -rX:Y URL" follows renames when picking the merge anchors just
like "svn merge -rX:Y WCPATH" follows renames.
The real answer to your question is: once the merge anchors are
picked, all merging is performed by pathname. This is part of what
Tom Lord refers to as Subversion's "anemic merge support".
> See the transscript below.
Now that I review your transcript, I think it fails in exactly the way
I would expect it to fail.
> Merging within one tree ("merge -r X:Y WC-PATH") nicely follows
> renames in 1.1.
You didn't post a transcript of this succeeding. I assume you were
merging individual files, or merging within a tree whose contents had
experienced no renames (although the tree itself may have moved
around).
> Are there plans to improve this?
Vague ones. See
<http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt>,
point C. The solution to this problem may involve some fairly deep
changes to the filesystem structure (we have to support "true
renames"), so it may be a 2.0 improvement.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-09-04 at 11:29, Folker Schamel wrote:
> The second from also follows renames "somehow" when using the URL@REV syntax.
> But in case of merging this "somehow" is not very useful.
>
> I suppose the reason for your decision is not because it is not useful,
> but because of its implementation complexity, right?
Actually, this might be a case of an implementation that is doing
something different that what we actually decided. Hm, watch for
replies on this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Folker Schamel <sc...@spinor.com>.
Ben Collins-Sussman wrote:
> On Sat, 2004-09-04 at 08:19, Folker Schamel wrote:
>
>>Hello!
>>
>>Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
>>
>>However, when merging changes from trunk into a branch or vice versa
>>("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
>>rename tracking seems to fails.
>>
>>See the transscript below.
>>
>>The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
>>
>>I suppose this is a more fundamental problem, but neverthanless:
>>Are there plans to improve this?
>
>
> No, because we've made a deliberate UI choice here.
>
> We've decided that
>
> svn subcommand [-rX[:Y]] wcpath
>
> ..will follow renames, whereas
>
> svn subcommand [-rX[:Y]] URL
>
> ..will not follow renames.
The second from also follows renames "somehow" when using the URL@REV syntax.
But in case of merging this "somehow" is not very useful.
I suppose the reason for your decision is not because it is not useful,
but because of its implementation complexity, right?
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-09-04 at 09:42, Ben Collins-Sussman wrote:
> > I suppose this is a more fundamental problem, but neverthanless:
> > Are there plans to improve this?
>
> No, because we've made a deliberate UI choice here.
Actually, I don't think we did; I think that choice was made by the
implementors, not on the mailing list. Looking at the plan in issue
#1093, URLs were supposed to peg at HEAD by default.
(How do you get to a deleted file? If you review the mailing list
conversation, I amended my plan to allow URL@REV in case 1. That
amendment didn't make it into #1093. See
http://www.contactor.se/~dast/svn/archive-2003-10/1520.shtml)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-09-04 at 08:19, Folker Schamel wrote:
> Hello!
>
> Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
>
> However, when merging changes from trunk into a branch or vice versa
> ("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
> rename tracking seems to fails.
>
> See the transscript below.
>
> The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
>
> I suppose this is a more fundamental problem, but neverthanless:
> Are there plans to improve this?
No, because we've made a deliberate UI choice here.
We've decided that
svn subcommand [-rX[:Y]] wcpath
..will follow renames, whereas
svn subcommand [-rX[:Y]] URL
..will not follow renames.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org