On Mon, Nov 09, 2009 at 06:28:09PM -0800, Shaun Pinney wrote:
> Hello,
>
> I'm getting tree conflicts following a merge but don't see why they should
> be occurring. Is there something I'm missing? Here are my steps:
>
> 1) Create branch1/ containing file.txt
> 2) Create branch2/ based on branch1/ - branch2/ now contains file.txt
> 3) Remove file.txt from branch1/ and commit
> 4) Merge from branch1/ to branch2/ and commit - file.txt is deleted from
> branch2/
> 5) Merge from branch2/ to branch1/ - causes a tree conflict on file.txt
>
> I would think the merge in step 4) would communicate to the server that the
> deletion of branch2/file.txt was due to a merge from branch1/, so a merge in
> the opposite direction (branch2/->branch1/) should not trigger a tree
> conflict. Is this possible?
No, unfortunately it's not possible.
The revisions you committed during steps 3) and 4) (let's call them
rX and rY) are two distinct identifiers for the same semantic change
which says "delete file.txt". But Subversion doesn't know that.
It only knows revision numbers, and paths.
When you tell svn to merge from branch2 to branch1 during 5), it checks
mergeinfo to see if branch2 already has received rY from branch1.
Since it does not, it tries to merge that revision. So the client asks
the server "tell me everything about rY" and the client receives a delta
telling it to delete file.txt.
> FYI - I'm using TortoiseSVN to do these operations. When I select "Edit
> Tree Conflicts" in TortoiseSVN it says "The last merge operation tried to
> delete/move/rename the file 'file.txt', but it was deleted, moved or renamed
> locally."
This message would be more correct if it said "... locally or in the
history of the merge target (i.e. branch2)."
Since the client is told to delete file.txt which is missing in the merge
target, the client figures that any of the following could have happened
since the branches were created:
- file.txt was deleted in both branches (svn mistakenly flags a conflict)
- file.txt was renamed in one branch and deleted in the other
- file.txt was renamed in both branches (potentially to different names)
The client does not know which of these happened (just that one of them
happened), and it cannot reliably find out more than it already knows.
So for now, we have to treat all these situations the same because we
cannot tell them apart from one another. That's why TortoiseSVN prints
this message.
We'd have to go back in time to the year 2000 and tell the original
designers of Subversion to make the client<->server interface a little
bit smarter about renames. Since then, people have built pretty much
everything else of Subversion around this somewhat limited interface.
We're working on amending this interface (search the dev@ archives for
'editor v2'), but it is a lot of work and will still take some time.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416077
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-10 10:57:33 CET