Subversion mergeinfo mixed up after merging trunk with branch

Question

I am testing the latest versions of Subversion, both the SVN command-line client and TortoiseSVN. (Until now, I have mainly used versions prior to the introduction of the mergeinfo properties, and the -reintegrate merge switch.)

I did a mandatory Googling, but either had really bad Google-fu, or what follows is actually a problem that no one explained and / or completely solved. I find this somewhat puzzling, as there are numerous reports of a problem - there are no problems finding these reports. I also find other discussions about mergeinfo support, but nothing that really matches and explains / solves what I experience.

I would appreciate any help updating my Google Fu or understanding what is happening and what to do about it.

Here:

• I have a trunk (and a working BASEd on it)

• I create a branch (and a working copy of BASEd on it)

• I make some changes to the WC trunk and commit

• I do some work in te WC branches and commit

• Now I combine work in the trunk with the WC of my branch, resolving any conflicts.

So far, everything is going as expected, but when I try to fix the result of the merger, but I get a message that the working copy is outdated and needs to be updated.

It does not make sense. The WC was updated just before the merger, and the purpose of the merger was WC. Therefore, nothing has changed in the repo.

Digging deeper, it seems that the mergeinfo property itself is the problem.

I have no problem recording the modified files individually, but after that the WC is still dirty / not fully authenticated, and I still cannot commit because the WC is not updated. So it seems that Subversion affects the mergeinfo property in both the repo and the WC.

In the event that I repeat this study, I have no problem performing WC updates first, and then commit. But I'm not sure that this will always be the case, or other options for this phenomenon will be more stringent for a solution. I'm also not going to try to “explain” this to neighboring Subversion users who do not have this as one of their “core tools”.

I have tested this for several years and I think this problem has been related to the implementation of mergeinfo and --reintegrate (1.5?) Functionality so far. Is it really so? And it is not addressed yet?

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

I have been using Subversion for many years and have described myself as a "powerful user." However, with this problem I am standing with my pants.

Adding

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

• Create a repository in the folder "C: \ Documents and Settings \ johndoe \ My Documents \ SVN \ Repo"

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

• In the Repo browser, create "file: /// C: / Documents and Settings / johndoe / My documents / SVN / Repo / Branches" (r2)

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

• In the trunk, create the text file test.txt, add it and copy (r3)

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

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

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

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

• Combine the connecting line with the branch. Right-click "C: \ Documents and Settings \ johndoe \ My Documents \ SVN \ WCs \ Branch1", Tortoise SVN, Merge. Merge type "Merge fix range", URL for merge: "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Trunk", Merge revisions :, Working copy: "C: \ Documents and Settings \ johndoe \ My Documents \ SVN \ WCs \ Branch1 ", everything else is by default. The Conflict Allow Later dialog box. (without new edition)

• Eliminate the conflict. Right-click the file, Tortoise SVN, Edit Conflicts. In TortoiseMerge, check and select "Before them", click "Mark as allowed", save and exit. (without a new edition).

• Try committing changes to Branch1.

At this moment 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 merger, the working copy was relevant. After that, no new changes were created (repo HEAD is still r6), and now my working copy is not updated.

Investigating further, it seems that updating WC for Branch1 already at stages 9 and 10 makes the problem go away. Again, this makes no sense to me: i) The dialog box at the end of the update does not say anything as actually updated, and ii) The same thing that has changed in the industry has already been completed. Thus, in my opinion, a WC is “clean” (nothing incomplete) and updated (nothing in the repo contributes to the WC).

The only thing the update does is change the BASE of the working copy of Branch1 from r4 to r6. This is somehow significant, but now my head is spinning too much so that I can cover the details.

I would be grateful for any fresh thoughts that will make me see what is happening here.

Appendix 2

Further, trying to clarify my thinking: FAQ, which was pointed out:

When a Subversion transaction is completed, the client only hits the version numbers of the nodes that the commit commits, and not all the nodes in the working copy. This means that in one working copy the files and subdirectories may be in different versions, depending on when you last had them. In some operations (for example, a modification directory property), if a newer version of node is in the repository, the commit will be rejected to prevent data loss.

I interpret "node" as "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Branches / Branch1" in my case. As I can see, there is no "later version of [this] node" in the repository. In general, the HEAD repo is r6, but the latest version of the node in question is r4.

Answer 1

It has nothing to do with mergeinfo support, but with what's in the folder support has been changed (ok, in this case the merge information property).

See the FAQ about this.

Answer 2

You are not alone: ​​I see it too. This is not like what causes the problem, and appears when you try to transfer properties to a folder in which there are children from a later version. So, in a sense, there is a later version of your node: the version from the later version has different child nodes than the version from the earlier version. I have not looked at the code, but I think that these children are stored on node in a similar way to saving properties.

Answer 3

After some experimentation, Stefans' answer gives a little more meaning. He is absolutely right that this does not apply to the mergeinfo property. I checked this by putting my own custom property in the top folder of my working copy of the branch.

I'm still wondering the wording

In some operations (for example, modifying directory properties) if a newer version of node is in the repository, the commit will be rejected to prevent data loss. Since the branch (branch produced r4) I

• create a WC of this branch (both the top directory and the only file in this directory are both modern and clean (without any unmanaged changes) at this stage.
• edit the file and commit (HEAD - r5, COMMITTED from the directory - r4, remember the r5 file)
• put the property in a directory in the WC

And again, when I try to make a mistake, I get an error. The problem is the node folder.

SVN STAT gives:

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

DIFF shows only one change to the folder (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 database in the r4 directory, HEAD is also r4, and I have one inconsistent change. I don’t see what kind of conflict could be.

If anyone can shed light on this, I will be very grateful. What am I missing?

Experimenting further, making a similar sequence, but adding the file to the directory and not adding the property, such a conflict does not exist.

So yes, this is due to properties in particular, and the question I have is if anynoe can describe the scenario in which the conflict occurs?