views:

368

answers:

5

[answer auto-selected by bounty system against my will]

I'm using subclipse, and always when delete a folder in Eclipse, and try to commit it, the following errors raise:

svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)

Deleting and commiting via command line works fine, but what's wrong with doing it via subclipse? Is anyone more experiencing this problem?

(I experienced this problem in Ubuntu 9.10 and 10.04; last Eclipse version; and subclipse 1.4 - as the next versions of subclipse have much more bugs)

--updated: Its when I delete folders, not files

A: 

i think if you UPDATE before that it should work.. it did work for me

praksant
You mean update before commit, not update subclipse version, I hope. There's nothing to update (so, the update button is disabled), I'm the only one in this svn branch.
Tom Brito
yes, i have this same problem in eclipse, that somehow deleted files didn't want to commit with the same error. I googled than, that i should UPDATE to HEAD in team submenu, so svn will detect those changes - deleting files. it looks like bug to me.
praksant
sorry, i say it wrong, its not files, its folders. By the way, I'll try, I'm not getting to reproduce it now, i don't now why. Maybe is something date related.. i dont know.
Tom Brito
as luiscolorado wrote, that error looked like file was deleted through operating system, subclipse wasn't somehow informed about that, and there was some kind of a mismatch between filesystem and subversion, maybe it thinks it was changed outside your session, so it needs to be updated.. it shouldn't make any problems, as files are not changed, so no manual merges aren't needed.
praksant
Yes i had problems with folders. i'm not sure about files now..
praksant
I had problems deleting from the OS some time ago, but its not the case now. It looks like a bug to me, too.
Tom Brito
No no, i didn't say i had problems deleting from OS. I tried to say it looks like eclipse deleted it in some OS way, and it should tell svn but it didn't, so you have your working copy out of sync. Maybe you have different problem, but it sounds very similar to me.
praksant
A: 

Tom,

You might want to try TortoiseSVN, and manually update the project workspace. Find the location of your project directory in your hard drive, and then try TortoiseSVN (or the command line if it's your preference) to do the update.

A frequent cause of this problem is to delete the directory without "informing" SVN. For instance, if you manually delete the directory using the operating system instead of using SVN, you will have this problem.

If you removed the directory before you installed the subversion plug-in, but the project already existed in the repository, you will experiment this problem. A solution, in this case, would be to recreate the directory, updating/committing, and then delete again the directory.

Good luck.

luiscolorado
I'd deleted from eclise. This Tortoise is a svn command line? cause it works fine in command line, now I want it to work in subclipse.
Tom Brito
No, it's a graphic tool that integrates to Windows Explorer. It is pretty cool. Look at http://tortoisesvn.tigris.org/. Download and install. The instructions come in a Windows help file, and are pretty clear. If you right click on any file or directory controlled by svn at Windows Explorer, you will notice options like check out, clean up, update, etc. Both Subclipse and Tortoise are visual interfaces for SVN. Subclipse is in Eclipse, and Tortoise in Windows. Subclipse has some bugs, bug I think that Tortoise is more dependable.If in trouble, close Eclipse and use Tortoise.
luiscolorado
+3  A: 

Isn't that addressed by the Subclipse FAQ?

Whenever you see "out of date" in an error message it means that the revision of the item in the repository is newer than the copy in your local working copy.
The solution is always going to be to run an update, so that your working copy is up to date with the repository, and then do the commit again (assuming that the update did not generate any conflicts).

  • For files, this is usually pretty easy to understand how and why this happens.
  • However, Subversion also versions folders, and it is usually with folders that this problem most often happens.
    Subversion does not allow you to delete/rename a folder OR change its versioned properties, UNLESS the local copy of the folder is at the HEAD revision of the folder in the repository.

Your next question might be:
"OK, I can maybe understand that, but why is my folder out of date? I am the only person working in this repository."

That is a valid question, the answer lies in the way that Subversion works.
When you commit a change to a file, the revision of the file in your working copy is updated to that new revision when the commit completes, however the version of the parent folder(s) of that file is not updated.
This is because there may have been adds/deletes to other files in that folder and until you have run an update, the folder is not really at that new revision.
This is called "mixed revision working copies".

In summary, the answer is always to do an update so that the folder or file is updated to its HEAD revision.


About "Mixed Revision Working Copies":

One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers.

One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa.
Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people.

The fact is, every time you run svn commit your working copy ends up with some mixture of revisions.
The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions

(and that is why, I believe, you cannot reproduce your "out of date" message on subsequent commits with folder deleted: your update did solve the "mixed revision" state.)

Mixed revisions have limitations

You cannot commit the deletion of a file or directory that isn't fully up to date.
If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.

VonC
ok, but as already commented in praksant's similar answer, do an update does not work for me.
Tom Brito
@Tom there nothing to update now. but at one time, they must have a mixed revision, which may have solve itself through the command-line. And now you cannot reproduce the issue. Because there is no more mixed revisions.
VonC
I could't reproduce when I wanted to, but right now I'd deleted a file and a directory, commited the file, and the directory cannot be commited, as a fail occur. And I cannot update (the update buttons is disabled because there is no update to do. Even if I re-synchronize). So the update tip does not help me.The only workaround is still use svn command line. Looks like a Subclipse unrecognized bug.
Tom Brito
A: 

Have you tried the CLEANUP command?

O Engenheiro
looks like subclipse does not offer it.
Tom Brito
See here http://subclipse.tigris.org/svnant/svn.html#cleanup
O Engenheiro
A: 

The only working way in same cases is via command line. The subclipse is still not perfect..

Tom Brito