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
Received on Sun Sep 5 16:11:15 2004