You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ulrich Eckhardt <ul...@dominolaser.com> on 2011/08/04 12:24:38 UTC
Merging copy operations
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?
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?
Uli
--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************
Re: Merging copy operations
Posted by Stefan Sperling <st...@elego.de>.
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@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.
Re: Merging copy operations
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
On Wednesday 10 August 2011, Johan Corveleyn wrote:
> I think what you're describing is issue #2685:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2685 (Move + Merge
> => lose modifications)
Yes, this is exactly what I was stumbling over.
Thanks to Andreas and Stefan, too, that explains the issue.
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Re: Merging copy operations
Posted by Andreas Krey <a....@gmx.de>.
On Wed, 10 Aug 2011 23:54:24 +0000, Johan Corveleyn wrote:
...
> I think what you're describing is issue #2685:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2685 (Move + Merge
> => lose modifications)
...
> Also, I'm not sure if mergeinfo will be a problem. Maybe you should
> just try it with a test repository.
The script in https://gist.github.com/1139064 demonstrates the problem
of issue #2685, which is five years old; before mergeinfo even existed.
It may well be that you lose some mergeinfo as well in the process.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Merging copy operations
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Aug 4, 2011 at 12:24 PM, Ulrich Eckhardt
<ul...@dominolaser.com> 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?
>
> 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
issue comments.
Also, I'm not sure if mergeinfo will be a problem. Maybe you should
just try it with a test repository.
--
Johan