Subversion mergeinfo messed up after merging trunk to branch

I am testing recent versions of Subversion, both the SVN command line client and TortoiseSVN. (Up to this point I've been using mostly versions previous to the introduction of the mergeinfo properties and the --reintegrate merge switch.)

I've done the obligatory Googling, but either have really bad Google-fu or what follows is actually a problem that no-one has explained and/or solved thoroughly. I find that somewhat puzzling since here are numerous reports on the problem - no problem in finding those reports. I also find other discussions on the mergeinfo prop's, but nothing that actually matches and and explains/solves what I experience.

I would appreciate any help in up'ing my Google-fu or understanding what goes on and what to do about it.

Here goes:

1. I have a trunk (and a working copy BASEd on it)

2. I create a branch (and a working copy BASEd on it)

3. I do some changes in the WC of the trunk and commit

4. I do some work in te WC of the branch and commit

5. I now merge the work in the trunk to the WC of my branch, resolving any conflicts.

So far all goes as expected, but when I try to commit the result of the merge, but I get a message stating that the working copy is out-of-date and needs to be updated first.

This makes no sense. The WC was up-to-date immediately prior to the merge, and the target of the merge was the WC. So nothing at all should have been changed in the repo.

Diging deeper it seems that it is the mergeinfo property as such that is the problem.

I have no problem commiting the changed files individually, but after that the WC is still dirty/not-fully-commited and I still cant commit because the WC is not up-to-date. Thus, it seems that Subversion has been touching the mergeinfo property both in the repo and in the WC.

In the case that I am repeating for this investigation I have no problem doing the update of the WC first, and then committing. But I am not sure this will always be the case, or other variants of this phenomenon will be tougher to solve. I also do not look forward to trying to "explain" this to nearby Subversion users, who do not have this as one of their "primary tools".

I have tested this to-and-fro for several years and I think this problem has been there from the introduction of the mergeinfo and --reintegrate functionality (1.5?) up to now. Can this be so? And it is still not adressed?

My current tests have been done with both the command line client (installed from CollabNetSubversion-client-1.6.17-4.win32.exe) and TortoiseSVN (TortoiseSVN-1.6.16.21511-win32-svn-1.6.17.msi), and I get the same results.

I've been using Subversion for many years now and have described myself as a "power-user". Still, with this issue I stand with my pants down..

Addendum

Here are the steps with which I can reproduce the problem:

1. Create a repository in "C:\Documents and Settings\johndoe\My Documents\SVN\Repo"

2. With the Repo browser, create "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Trunk" (r1)

3. With the Repo browser, create "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Branches" (r2)

4. Create a working copy of the trunk in "C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Trunk" (no new revision)

5. In the trunk, create a text file test.txt, add it and commit (r3)

6. Create a branch of the trunk in "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Branches/Branch1" (r4)

7. Create a working copy of this branch in "C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1" (no new revision)

8. In the working copy BASEd on Trunk, add a line of text to test.txt and commit (r5)

9. In the working copy BASEd on Branch1, add a line of text to test.txt and commit (r6)

10. Merge the trunk to the branch. Right click "C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1", Tortoise SVN, Merge. Merge type "Merge a range of revisions", URL to merge from: "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Trunk", Revisions to merge: , Working copy: "C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1", everything else default. In Resolve Conflict dialogue "Resolve all later". (no new revision)

11. Resolve the conflict. Right-cl开发者_如何学编程ick the file, Tortoise SVN, Edit Conflicts. In TortoiseMerge, mark and select "Theirs before mine", click "Mark as resolved", save and exit. (no new revision).

12. Try to commit the changes in Branch1.

At this point I get a message

Commit
C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1
Commit failed (details follow): 
Directory '/Branches/Branch1' is outof date 
You have to update your working copy first.

This does not make sense to me: Before the merge the working copy was up-to-date. After that there has been no new revisions created (repo HEAD is still r6), and now my working copy is not up-to-date.

Investigating further, it seems like an Update of the WC for Branch1 as early as between steps 9 and 10 makes the problem go away. Again, this makes no sense to me: i) In the dialogue at the end of the update, nothing is reported as actually updated, and ii) The one and only thing changed in the branch is already commited. So, in my view the WC is both "clean" (nothing uncommitted) and up-to-date (nothing in the repo to contribute to the WC).

The only thing that the update actually does is to change the BASE of the working copy of Branch1 from r4 to r6. This is somehow significant, but right now my head is spinning too much for me to nail the details down.

I'd appreciate any fresh thoughts that will make me see what goes on here.

Addendum 2

Further trying to clarify my thinking: The FAQ that was pointed to says

When Subversion commits, the client only bumps the revision numbers of the nodes the commit touches, not all nodes in the working copy. This means that in a single working copy, the files and subdirectories might be at different revisions, depending on when you last committed them. In certain operations (for example, directory property modifications), if the repository has a more recent version of the node, the commit will be rejected, to prevent data loss.

I interpret "the node" as being "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Branches/Branch1" in my case. As I see it, the repository does not have "a more recent version of [that] node". Overall, the HEAD of the repo is r6, but the most recent version of the node in question is r4.

It has nothing to do with the mergeinfo prop, but with the fact that a prop (ok, in this case the merge info property) was modified on a folder.

See the FAQ entry about this.

You're not alone: I see this too. It doesn't appear to be something that causes problems, and appears to exhibit itself when you try to commit properties to a folder which has children from a later revision. So there is a later version of your node in some sense: the version from the later revision has different child nodes than the version from the earlier revision. I've not looked at the code, but I imagine that these children are stored on the node in a similar manner to the way properties are stored.

After doing some experiments Stefans answer makes a bit more sense. He is absolutely correct about this not being specific to the mergeinfo property. I verified this by putting my own arbitrary property on the top folder of my working copy of the branch.

I am still curious re the formulation

In certain operations (for example, directory property modifications), if the repository has a more recent version of the node, the commit will be rejected, to prevent data loss. Starting at the time of branching (the branch has produced r4) I

• create a WC of this branch (both the top directory, and the only file in that directory are both up-to-date and clean (no uncommited changes) at this point.
• edit the file and commit (HEAD is r5, COMMITTED of the directory is r4, commited of the file is r5)
• put a property on the directory in the WC

And again, when I try to commit I get the error. The problem is with the folder node.

SVN STAT yields:

C:\SVN T2\WCs\Branch1>svn stat
 M      .

A DIFF shows exactly one change, to the folder (the added property):

C:\SVN T2\WCs\Branch1>svn diff

Property changes on: .
___________________________________________________________________
Added: je:dummy
   + Dummy value

Finally, INFO says:

C:\SVN T2\WCs\Branch1>svn info
Path: .
URL: file:///C:/SVN%20T2/Repo/Branches/Branch1
Repository Root: file:///C:/SVN%20T2/Repo
Repository UUID: 009c3a97-e14f-234a-92e9-d30c537e29f9
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: SEEKDAHLJ
Last Changed Rev: 4
Last Changed Date: 2011-07-27 09:26:53 +0200 (on, 27 jul 2011)

So my BASE of the directory is r4, the HEAD is also r4, and I have one uncomitted change. I can not see what conflict there could possibly be.

If anyone can shed any light on this I would be greatful. What am I missing?

Experimenting further, doing a similar sequence but adding a file to the directory rather than adding a property, there is no such conflict.

So yes, this is connected with properties in particular, and the question that I have remaining is if anynoe could describe a scenario where a conflict actually occurs?