How do I correct "Commit Failed. File xxx is out of date. xxx path not found."

Question

I have recently run into a particularly sticky issue regarding committing the result of a merge in subversion. Our Subversion server is @ 1.5.0 and my TortoiseSVN client is now @ 1.6.1.

I am trying to merge a feature branch back into my trunk. The merge appears to work okay; however, the commit fails with the following error message.

Commit failed (details follow):
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found
You have to update your working copy first.

My working trunk is up to date. I have even checked out a new one into a different folder to make sure there wasn't any local cruft messing with the merge. I have done some more research into this and I think part of the problem is user error. I think our problems are:

1. We had some developers committing work with a subversion client before 1.5 and some after. I believe this has the potential to corrupt the merge info.
2. In other branches we have performed partial merges. That is, we did not always perform merges at the root of the branch. This was to facilitate updating Flex and .NET efforts within the same branch.
3. We performed cyclic (reflexive) merges on our branch. This was done because we had multiple parallel branches and we wanted to periodically update our branch with the latest code in trunk.

All of these things are explicitly not recommended by the Subversion book/team. We have learned our lesson and now know the best practices. However, we first need to merge and commit our latest branch.

What it the best way to correct the problems we are encountering?

Would deleting all the merge info in the trunk and branch be a viable solution? No. I have done this but it does not resolve the error that I am getting above.

Answer 1

Oh boy! This looks bad! The only option that I can think of is that the working copy is corrupt.

Try deleting the working copy, performing a fresh checkout and performing the merge again.

If that doesn't work, then log a bug.

Answer 2

I have been unable to find a satisfactory solution to this problem; however, I have found an unsatisfactory solution.

I have deleted all the files within trunk and committed these changes. I then exported my branch code into the trunk, added all the files, and made a large commit. This had the affect of my trunk mimicking my branch 1:1 (which is what I wanted anyway).

Unfortunately, this creates a large divide as the history of all the files is now "lost". But due to time constraints there didn't appear to be any other option.

I will still be interested in any answers that others may have as I would like to know what the root cause was and how to avoid it in the future.

Answer 3

I think I've seen something similar when folders were moved on the server but the working copies were still bound to the older SVN folder structure. Not sure if anyone moved things around in your trunk before you had the chance to merge the branch.

Is that a possibility?

Answer 4

I've had the same issue today and I've not done any intermediate merges so from your opening post only #1 might apply - however i have made commits both from an svn client in ubuntu as well as tortoisesvn in windows. Luckily in my case no changes to the trunk were made so I could just replace the trunk with the branch. Possibly different svn versions then? That's quite worrying.

If you use the svn move / copy /delete functions though no history is lost in my case - i svn moved the trunk and then svn moved the branch to trunk.

Answer 5

I had the same problem while trying to commit my working copy. What I did was add the folder that Subversion reports as "path not found" to the ignore list. Commit (should succeed). Then add the same folder back to Subversion. Commit again.

Answer 6

This looks like a problem with the svn:mergeinfo property getting out of wack between the branch and the trunk.

Which leads to the following questions (forgive my command line instructions as I done use tortoise much):

1. Are you merging at the trunk root level or the sub folder level? In my experience it is always best to do at the root level, this way the whole trunk thinks it has been merged to rather than just part (this seems to confuse svn greatly in 1.5.0)

2. My next question is were you using the --reintergrate parameter? I can never remember how to get to this in tortoise, but when you are going back to the trunk from a branch then you should use this parameter.

3. Have you merged the trunk into the branch before you have reintegrated? This can help remove conflicts that you may see when you merge back?

4. Have you got any svn:mergeinfo properties on the branch that are not at the root level? This I have found always causes problems. You can always find this out by going svn -R pg svn:mergeinfo. You can then record the locations and revisions that were below the root, if you find them relevant then move them to the root by svn merge --record-only -r start:end <location> and then delete them from the sub root locations with svn pd svn:mergeinfo <location> You then need to commit these changes

5. Once you have all that is done try merging again.

Answer 7

I doubt it but maybe running svn cleanup on your working directory will help.

Answer 8

I had the same problem after merging a branch with a ton of changes back into my trunk. The only two solutions I could see was to do the svn move solution offered by Pacifika or manually merging the files with a diff tool. But I did find a workaround...

The machine that wasn't working was running Subversion client 1.6.5. I did the exact same thing on a machine with Subversion 1.5.4 and it worked! On both machines I did a 1) clean checkout of trunk, 2) svn merge ..., and 3) svn commit. My server is 1.5.x for what that's worth.

Hope this helps somebody.

Answer 9

I've just had similar problem but without any branching or merging to cause the problem. My workaround was to:

• svn export my working folder (including unversioned files) to a temp folder.
• rename the working folder a backup.
• svn checkout the trunk.
• copy all folder from temp export folder over new working folder.
• svn commit.

All seems fine now.

Answer 10

the last solution , also worked for me

Answer 11

thank u,the last solution,had helped me!

Answer 12

I was getting this on 1.6.2 server, 1.6.8 tortoise. All on Windows, no merges in this branch.

I renamed a directory and somehow (possibly due to AnkhSVN) two of the files within the directory were being marked as "replaced" rather than "normal". There were some additional minor changes to other files within the directory.

Reverting the files marked as replaced fixed the problem.

Answer 13

I just had this problem, and the cause seemed to be that a directory had been flagged as in conflict. To fix:

svn update
svn resolved <the directory in conflict>
svn commit

Answer 14

I faced exactly same issue today. I was having Tortoise SVN 1.6.5. I simply installed the higher version i.e. 1.6.9 and re-tried check-in the changes. It worked flawlessly. I guess it is some bug in SVN client that got fixed after 1.6.5.

Answer 15

I encountered the same problem, beat my head up and found that I had changed the directory in the represotory from "/" to "/trunk" and forgot to do the "Switch" command, in TortoiseSVN!

Answer 16

I encountered the same problem, beat my head up and found that I had changed the directory in the represotory from "/" to "/trunk" and forgot to do the "Switch" command, in TortoiseSVN!