On Thu, Aug 04, 2011 at 12:24:38PM +0200, Ulrich Eckhardt wrote:
> Hi!
>
> I'm refactoring code and in that context I moved parts of one file to a
> separate file, so I copied trunk/A to trunk/B and then hacked the two so that
> each contained one part of the code. Then, when the whole works again, I
> commit the whole in a commit. First question here: I consider that a normal
> approach that should be supported, any objections here?
No objections to this approach.
> Then, lateron, I want to merge the changes. I then merge the revision from
> trunk to the stable branch. What I noticed there is that in the branch, the
> "copy from" property of the newly-created file "stable/B" points to "trunk/A",
> while I would have expected it to point to "stable/A" instead!
During a merge, Subversion does not replay copy operations within the
target branch. Doing so would be a lot more complicated than what it
is currently doing. If copyfrom points back to the merge source the
copyfrom path_at_rev will always exist. If copies are instead replayed within
the merge target and the copy source does not exist within the merge target
the copy cannot be replayed and tree conflict handling needs to kick in.
The behaviour you describe was implemented at long time before tree
conflicts even became a topic on the development roadmap.
So I would say this behaviour is simply the result of organic growth.
> Second question
> here: In what case does the existing behaviour make sense? I'd say that when
> merging, such copy-from paths must also be translated to the new tree.
I agree. But it hasn't been implemented yet. I think it should
eventually be tackled, possibly when we get to the point where we
can try to improve tree-conflict handling for moves.
> However, if the path was outside the "from" tree, it shouldn't be translated,
> so there the current behaviour would be expected.
I disagree here. I think a tree conflict should be flagged in this case.
Ideally the user would be presented with an interactive conflict
resolution prompt that helps with resolving the tree conflict.
But interactive conflict resolution for tree conflict is also still
on the TODO list.
> What I'm not sure is if this has an effect on mergeinfo, I haven't actually
> tried that, so I'm guessing here.
Whatever happens to mergeinfo is a separate question.
We can define the way it should behave and then implement that.
We don't need to restrict ourselves by what merge-tracking currently
does in this particular case.
Received on 2011-08-11 14:38:17 CEST