How to fix the "Commit Failed" error. The xxx file is out of date. Xxx path not found. "

Question

Recently, I came across a particularly sticky problem associated with obtaining the result of a merger in subversion. Our Subversion server is @ 1.5.0, and my TortoiseSVN client is now @ 1.6.1.

I am trying to merge a function branch back into my chest. The merge seems to work fine; 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 updated. I even checked the new one in a different folder to make sure there was no local merge torsion mess. I did some more research on this, and I think part of the problem is user error. I think our problems are:

• We had some developers who work with the subversion client before 1.5 and after. I believe that this could lead to corruption of the merger information.
• In other branches, we performed partial merges. That is, we did not always perform mergers at the root of the branch. This should have made it easier to update Flex and .NET efforts in the same branch.
• We performed circular (reflective) mergers on our branch. This was done because we had several parallel branches, and we wanted to periodically update our branch with the latest code in trunk.

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

What is the best way to fix the problems we face?

Would deleting all merge information in the trunk and branch a viable solution? No. I did this, but it does not resolve the error that I get above.

Answer 1

I had the same problem today and didn’t do any intermediate merges, so only # 1 could be applied from your introductory message, however I made a fix both from the svn client in ubuntu and with interleaving in windows. Fortunately, in my case there were no changes in the trunk, so I could just replace the trunk with a branch. Perhaps different versions of svn? This is pretty troubling.

If you use the svn functions move / copy / delete, although in my case the story is not lost - I svn moved the trunk, and then svn moved the branch to the trunk.

Answer 2

I just had this problem and the reason was that the directory was marked as conflicting. To fix:

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

Answer 3

I was getting this on turtle server 1.6.2, 1.6.8. Everyone on Windows does not merge into this thread.

I renamed the directory and somehow (possibly due to AnkhSVN) the two files in the directory are marked as "replaced" and not "normal". Some minor changes were made to other files in the directory.

Returning files marked as replaced resolves the issue.

Answer 4

I had the same problem trying to commit my working copy. What I did was add a folder in which Subversion would appear as “path not found” in the ignore list. Commit (must succeed). Then add the same folder back to Subversion. Try again.

Answer 5

I had a similar problem, but without branching or merging to cause the problem. My workaround was this:

• svn exports my working folder (including unversioned files) to a temporary folder.
• rename the working folder to the backup.
• svn check the trunk.
• copy the entire folder from the temp export folder on top of the new working folder.
• svn commit.

Now everything seems beautiful.

Answer 6

I also had the same problem and solved it as follows:

 svn resolve --accept=working <FILE/FOLDER NAME> svn cleanup svn update <FILE/FOLDER NAME> svn commit <FILE/FOLDER NAME> -m "Comment" 

Hope this helps you :)

Answer 7

I know this is an old post, but this problem is still quite common. The easiest way to find this is to rename / delete the .svn / all-wcprops file in the affected folder, then start the update and commit.

Answer 8

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

Try deleting the working copy, performing a new check, and merging again.

If this does not work, write down the error.

Answer 9

I could not find a satisfactory solution to this problem; however, I found an unsatisfactory solution.

I deleted all the files inside the body and made these changes. Then I exported the branch code to the trunk, added all the files, and made a big commit. This affected my chest, imitating my 1: 1 branch (which is what I wanted).

Unfortunately, this creates a big gap, since the history of all files is now "lost". But due to time constraints, there seemed to be no other option.

I will still be interested in any answers that may arise from others, as I would like to know what was the main reason and how to avoid this in the future.

Answer 10

I had the same problem after merging a branch with tons of changes back to my trunk. The only two solutions I could see were to make the svn move solution proposed by Pacifika , or manually merge the files using the diff tool. But I found a workaround ...

On a machine that did not work, the Subversion 1.6.5 client was launched. I did the same on a machine with Subversion 1.5.4 and it worked ! On both machines I did 1) a clean boot check, 2) svn merge ... and 3) svn commit. My server is 1.5.x for what it costs.

Hope this helps someone.

Answer 11

There was a similar issue with SVN 1.6.5 on Mac 10.6.5, upgraded to SVN 1.6.9, and commit was successful.

Answer 12

I think I saw something similar when folders were moved on the server, but working copies are still tied to the old SVN folder structure. Not sure if someone moved things in your trunk before you had the opportunity to merge the branch.

Is it possible?

Answer 13

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

This leads to the following questions (please forgive my instructions on the command line, since I used the turtle a lot):

• Are you going at the root line or subfolder level? In my experience, it is always best to do it at the root level, so the entire trunk thinks that it was integrated, and not just a part (this seems to be very confusing for svn in 1.5.0)

• My next question is: do you use the --reintergrate ? I cannot remember how to do this in the turtle, but when you return to the trunk from a branch, you should use this parameter.

• Did you bundle your trunk in a branch before you reintegrate? Can this help resolve the conflicts you might see when merging?

• Do you have any svn:mergeinfo on a branch that are not at the root level? I always caused problems. You can always find this by going to svn -R pg svn:mergeinfo . You can then record locations and revisions that were below the root if you find them relevant, and then move them to the root svn merge --record-only -r start:end <location> directory, and then remove them from the root sites from using svn pd svn:mergeinfo <location> . Then you need to commit these changes

• After you do all this, try draining again.

Answer 14

I doubt it, but svn cleanup might work in your working directory.

Answer 15

I ran into the same problem, cracked my head and found that I changed the directory in the representation from "/" to "/ trunk" and forgot to make the "Switch" command in TortoiseSVN!

Answer 16

Wow, it took me a while, because I used SVN through Eclipse. In the end, the only thing that worked for me was to commit all the unaffected files, then (with Eclipse closed) rename the project directory and reinstall the project from SVN. Glad it works correctly!

Answer 17

SVN does not seem to be a very reliable program. I had the same problem (using SVN with Turtoise) and it was solved by saving the contents of the .cs file and then returning 1 version. It showed such conflicts: "<<<<<<<<<filename my changes

======= code combined from the revision repository "

while I didn’t do anything special (only once returned the revision).

I replaced the contents of this file with the saved content, saved, and then selected through TortoiseSVN → Resolved. Then I could make changes to the repository.

Answer 18

I had the same problem when I tried to commit the remote package (which contains various java classes, but nothing from the package was needed anymore).

My solution / workaround to fix the problem:

• I returned the whole package
• deleted content first.
• sent deleted content
• Finally, I sent the remote package again (and it worked in most cases :-))

However, from time to time it was not possible to commit the remote package (which contains nothing)

My workaround:

• I created a dummy class in the package
• and after that I repeated the steps above

My last hint ...

But sometimes it helps just sync the package / project again, and after that, everything works fine again.

About my configuration:

• Eclipse neon
• SVN Interface: JavaHL (JNI) 1.8.13 (r1667537)
• VisualSVN Server Manager Version: 3.3.1

Maybe I can help someone with one of my hints.

Answer 19

I had the same problem, I don’t know what is the reason for this, but I fixed it by typing the terminal

 svn update 

and then I commit and the boom will work!