Am 17.10.2012 12:00, schrieb Stefan Sperling:
> On Tue, Oct 16, 2012 at 06:35:21PM +0200, Stefan Sperling wrote:
>> Again, sticking to simple branching/merging patterns where all merges
>> happen between directly related branches makes things a lot easier.
>
> Hi again Sven,
>
> I've looked at this some more trying to come up with a simpler solution.
You are really into this problem. Thank you for your effort! :)
> It turns out that the root of all evil really is the mixed-revision
> copy you've made to create the first branch. If the branch is created
> by copying URLs the add vs. add tree conflict problem disappears.
As written in my first reply: The mixed-revision copies seem to be a
problem with the usage of TortoiseSVN. I will check the next time when I
create abranch using this 3rd party tool.
> Also, a 2-URL merge is not strictly required to run the merge between
> the two unrelated (or "cousin") branches. But you need to sync the
> branch you're merging from to trunk first, which moves the common
> ancestor point forward in history [...]
> This requires a
> record-only merge to work around the mixed-revisionness of the branch
> but is otherwise straightforward.
>
> Below is a unix shell script I used to reproduce the problem.
> See the comments inside the script for more details.
>
> svn add $trunk/foo
> svn ci $trunk -m "add new file"
>
> # mixed-rev copy!
> svn copy $trunk $branch1_url -m "creating branch 1"
> # doing this instead would prevent tree conflicts below:
> # svn copy $trunk_url $branch1_url -m "creating branch 1"
Doing a "svn up" before the "svn copy" in the root of the working copy
should the trick as well, right?
> # sync branch1 to trunk, moving the common ancestor used for the merge
> # beyond the creation of 'foo' to avoid the above tree conflict
> #
>
> # r2 created 'foo' which exists on branch1 because of mixed-rev copy.
> # Mark r2 as merged into branch1 to avoid another add vs. add tree-conflict.
> svn up $branch1
> svn merge --record-only -c2 $trunk_url $branch1
Doing this requires that you know a lot about what happens in other
branches. There could be hundreds of commits in each of the branches and
trunk by multiple people over several month.
Why is it not possible for SVN to see that the source files are the same
and the trunk changed the contents that are now valid?
See also my other mail for a similar question.
Best regards
Sven.
PS: Sorry for cross referencing to other mails but I don't see an easy
option to reply to multiple mails in one new mail.
Received on 2012-10-17 17:31:20 CEST