On Mon, Jun 17, 2013 at 04:01:43PM -0500, C M wrote:
> Well, for what its worth, I was able to complete the "merge" following
> steps 3 -6 in this article.
>
> http://kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html
>
> I don't understand why SVN behaved the way it did and prevented the branch
> to trunk merge as expected..
For some reason, the revision you merged did not carry out
the 'add' action for paths changed by the merge. The merge
performed only an 'edit' (i.e. content modification) action,
and it tried to perform this action on a path which didn't exist.
It is a bit tricky for Subversion to figure out what happened here.
In your particular case, the conflict description 'local delete vs.
incoming edit' is confusing. It is used because:
- Subversion currently has no intelligent way of figuring out what
conflicting changes happened in your repository history, so most
conflict descriptions are more or less educated guesses, and are
*not* strictly based on what actually happened. They are correct
most of the time, but not every time.
- The conflict descriptions were written with the assumption that merges
are performed between ancestrally related branches.
In your case, the latter isn't true. You have a new directory /trunk,
which is empty, and you are trying to merge changes into it. Performing
an 'edit' on something that doesn't exist makes no sense. The thing to
be edited must be created with an 'add' action before it can be edited.
Subversion treats addition and deletions of objects as a first class
operation -- an edit changes an existing object.
When the conflict is flagged, Subversion sees an attempt to edit
an object which does not exist. Assuming the branches are ancestrally
related, and assuming that all changes are merged from the merge source,
the missing object could only be 'deleted' in the target branch's history.
That's why the descriptions says 'local delete'. Does that make sense?
In your case, the conflict description would ideally say something like
'incoming edit for a path which never existed in this branch's history'.
But Subversion is currently not smart enough to describe the conflict in
this way.
In any case, your merge command doesn't seem to be making useful
changes. It looks like you were excluding one or more revisions
which created objects on your branch. If you include those revisions
in your merge to trunk, the merge should succeed.
Received on 2013-06-18 11:32:14 CEST