CODEWITHSUNDEEP
svntortoisesvn
user147373
user147373

Reputation:

can't commit to svn because working copy is always out of date

I'm trying to commit some work, but svn always fails and tells me that a file I modified is out of date. I tried updating first, that doesn't work. Cleanup doesn't work. If I revert the file, copy my changes over and try that, it still fails. It isn't just a particular file either, if I revert the whole thing back to a previous revision, and modify any file, this problem still occurs.

I am out of ideas. Anyone have anything?

Thanks.

Upvotes: 10

Views: 15918

Answers (6)

suhas_partha
suhas_partha

Reputation: 61

If you are using eclipse, right click on the project and do update version.. and then select working copy in the drop down, select options that notify you about the merge conflicts. Refer the image for more info.enter image description here

Upvotes: 0

Andreas L.
Andreas L.

Reputation: 2933

I had this error with renaming java packages (directories for svn).

I solved it by doing "Override and Update" on deleted directory (got empty one in my project). Then commited the new directory with files. After that deleted the renamed in project again and commited it again.

Upvotes: 1

Fred
Fred

Reputation: 91

For me, this procedure worked: On a single file, I had reverted to an old version of the file. When I wanted to commit the project, I had the message that this particular file is out of date and it didn't commit.

What should be done is to copy the content of the file and get back to the latest svn version of this file.

Once it is done, copy to the file the content you saved and then commit. That worked for me.

Upvotes: 0

Thomas Jung
Thomas Jung

Reputation: 33102

If you can update your file the working copy seems to work properly.

Did you update the directory or only the file? I had situations when svn could not commit because the directory properties changed in the repository. An update on the directory solved this problem.

Another try is to use svn cleanup.

New checkout is the last resort.

Upvotes: 5

Upgradingdave
Upgradingdave

Reputation: 13076

Here's a common scenario I've seen cause a lot of people headaches. It's possible that you might be in this state:

  1. Working Copy is in broken state. SVN complains that file 'bar' under 'foo' directory is causing problems.
  2. Developer makes a backup copy of the foo directory.
  3. Developer deletes foo dir from working copy.
  4. Developer does svn update, foo and bar are reverted and svn is happy.
  5. Developer copies backup copy of foo back over into working copy and svn is no longer happy and no longer able to update and/or commit

The fatal mistake here was when the developer made a backup of dir 'foo', they also made a back up of all the hidden ".svn" directories nested inside foo.

So, the solution (in my experience), is to use tortoise svn's "export" capability to make a backup copy of foo. Tortoise svn Export will create a copy of the directory structure without any svn meta data (.svn dirs). This way, once you're back to step 3 and svn is happy, when you copy your backup back into your working copy directory, svn should be able to capture the changes correctly.

Then again, if it's only a single file you're creating a backup copy of, then, this won't help.

Upvotes: 1

Leventix
Leventix

Reputation: 3869

Try creating a fresh checkout, then copying your changes to it. I had some inexplicable problems with TortoiseSVN too, and this was the only thing that helped.

Upvotes: 5

Related Questions