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

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.

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.

I had the same problem when I tried to commit a deleted package (which contains various java classes but nothing from the package was necessary any more).

My solution / workaround in order to fix the problem:

• I reverted the whole package
• deleted the content first
• commited the deleted content
• finally I commited the deleted package again (and it worked in most cases :-))

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

My workaround:

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

My last hint...

But sometimes it helps simple to synchronize the package / project once more and after that everything works great again.

About my configuration:

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

Maybe I could help someone with one of my hints.

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

Had similar problem with the SVN 1.6.5 on Mac 10.6.5, upgraded to SVN 1.6.9 and the commit succeeded.

I had the same issue, don't know what is the reason behind it but i fixed by typing in terminal

svn update

and then I commit and boom it worked!

Thanks Jamie Bullock this Work for me

As per Jamie Bullock,

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

1. svn update
2. svn resolved
3. svn commit

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

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.

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.

I also had the same problem and I resolved the same by the following method

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

Hope this will help you :)

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.

Wow, this one took me a while to solve, as I was using SVN through Eclipse. In the end, the only thing that worked for me was to commit all non-affected files, then (with Eclipse closed) rename the project directory, and re-check the project out from SVN. Glad it works properly now!

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.

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!

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.

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?

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.

Apparently SVN is not a very reliable program. I had the same problem (using SVN with Turtoise) and solved it by saving the .cs file's content and then going back 1 revision. This showed conflicts like this: "<<<<<<< filename my changes

======= code merged from repository revision "

while I haven't done anything special (just once set back a revision).

I replaced the content of this file with the saved content, saved, and then selected via TortoiseSVN ? Resolved. I could then commit the modifications to the repository.

I know this is an old post, but this problem still occurs fairly frequently. The simplest way I've found to resolve it is to rename/delete the .svn/all-wcprops file in the affected folder, then run an update and commit.