On Thu, Aug 4, 2011 at 12:24 PM, Ulrich Eckhardt
> 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?
> 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! 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.
> However, if the path was outside the "from" tree, it shouldn't be translated,
> so there the current behaviour would be expected.
> What I'm not sure is if this has an effect on mergeinfo, I haven't actually
> tried that, so I'm guessing here. What I think is that if "trunk" at some
> point acquired any mergeinfo, that mergeinfo implicitly applies to "trunk/B",
> too. If I now copy that file to a branch, it will preserve that mergeinfo
> (right?) so that now the file and the rest of the branch explicitly have
> different mergeinfo properties. At least I believe this can happen, which
> would be bad, because you typically want the mergeinfo to be restricted to the
> root of the branch.
> Is this a bug or am I doing something wrong?
I think what you're describing is issue #2685:
http://subversion.tigris.org/issues/show_bug.cgi?id=2685 (Move + Merge
=> lose modifications)
I don't know the details, but came across this issue when looking for
something else. You may be able to find some more explanations in the
Also, I'm not sure if mergeinfo will be a problem. Maybe you should
just try it with a test repository.
Received on 2011-08-10 23:55:12 CEST