46

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.

Sir Rippov the Maple
  • 7,491
  • 5
  • 42
  • 52
Ryan Taylor
  • 8,740
  • 15
  • 65
  • 98

21 Answers21

26

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
j b
  • 5,147
  • 5
  • 41
  • 60
  • To do this in IntelliJ, you'll want the Command Line Tool Support plugin. To get it, open File > Settings (or Ctrl+Alt+S) > Plugins. Click the "Browse Repositories" button. Search for "Command Line Tool Support" plugin. Click "Install" button on it. Restart IntelliJ. Now that it's set up, you can simply click Tools > Run Command (or press Ctrl+Shift+X) and run your commands within IntelliJ. – Jeremy Moritz Oct 11 '17 at 14:41
19

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.

Simon D
  • 4,150
  • 5
  • 39
  • 47
6

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 :)

Augustine P A
  • 5,008
  • 3
  • 35
  • 39
4

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.

David
  • 5,356
  • 2
  • 26
  • 39
4

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.

Tim Murphy
  • 4,892
  • 4
  • 40
  • 48
3

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.

svandragt
  • 1,672
  • 20
  • 38
  • I should have done that as well, however, given that this happened during a time crunch I wrongly exported my branch to trunk and committed the changes, thereby losing the history. Fortunately, I have not experienced this problem since. – Ryan Taylor Jul 14 '09 at 20:39
  • I think the answer of @simon-d below is the real solution. This is more like a workaround :) – Diego Fernández Durán Sep 15 '11 at 13:39
3

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.

R M
  • 31
  • 1
2

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!

George Vardikos
  • 2,345
  • 1
  • 14
  • 25
1

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.

Community
  • 1
  • 1
Chris Mumford
  • 21
  • 2
1

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.

Chisey88
  • 569
  • 6
  • 13
1

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

maxwoj
  • 11
  • 1
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.

Sir Rippov the Maple
  • 7,491
  • 5
  • 42
  • 52
  • It seems pretty bad. I've tried performing fresh checkouts but have not yet had any luck. Unfortunately, at this point my only recourse seems to be to delete all files in my trunk and export the branch to the trunk folder and re-add all the required files. – Ryan Taylor May 04 '09 at 17:37
1

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.

Ryan Taylor
  • 8,740
  • 15
  • 65
  • 98
0

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.

Andrew Cox
  • 10,672
  • 3
  • 33
  • 38
  • 1. We had been doing partial merges. We have stopped that practice. Though we do still create branches from a trunk sub-directory. 2. We could rarely get the --reintegrate option to work. I forget the error we received at the moment. We switched to specify the revisions we want to merge to avoid this error. 3. In general we merge the trunk into the branch before any merging back into trunk so we may reconcile merge issues in the branch. 4. There didn't seem to be any issues with the svn:mergeinfo properties. Typically we have one branch open at a time though we have on occasion had more. – Ryan Taylor Jul 24 '09 at 16:01
  • I believe our problems stemmed from several issues all of which have been resolved. 1. Our subversion clients were not at the same version. Some were merge unaware and made merge unaware comments. 2. We were performing partial merges ( with different Subversion client ) 3. Our Subversion server was 1.5.0. It was just updated to 1.6.3 last week. We have already had better merge experience than with the previous version. I think these all contributed to the errors we had above. – Ryan Taylor Jul 24 '09 at 16:04
0

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

Gren
  • 573
  • 2
  • 9
0

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!

David
  • 1
0

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.

Dick
  • 433
  • 5
  • 13
0

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!

Sworup Shakya
  • 1,328
  • 3
  • 16
  • 44
0

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
3JT
  • 13
  • 5
0

An interesting issue I ran into, that had a similar symptom, is the create date for the some of my project files on my Mac had been messed up (possibly currupted, but not quite sure).

I committed directory after directory, until I found the symptomatic directories. Made some adjustments in the file (unintentionally), then had the idea to re-attempt.

Worked like a charm. So some of your files create dates could be bad or incompatible with the svn set up (since I was copying from a base project, I think the create data may have been before the new repository was created).

AajhBajh
  • 21
  • 5
  • This occured on Mac OS, using PHPStorm with svn to commit to BeanStalk, just for further clarification. – AajhBajh Jul 11 '22 at 15:33
0

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?

Steve J
  • 667
  • 6
  • 10
  • No one had edited in trunk. Generally editing in trunk is forbidden as we are using the stable trunk method. Because we decided to start from scratch as in the answer above, I fear I will never know the real cause of the issue. – Ryan Taylor Jun 03 '09 at 02:33