| directory conflict because of svn:ignore [message #49028] |
Thu, 09 July 2009 10:49  |
Eclipse User |
|
|
|
When I try to commit the changes of the top directory of my project in
Eclipse to its sourceforge subversion repository, I get this error:
Merge conflict during commit
svn: Commit failed (details follow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating.
Checking on the internet I've found some articles that was mentioning the
svn:ignore property of the directory as the cause of the problem.
Actually svn:ignore turns out to be different (older) on the sourceforge
repository.
But the proposed solution, to update the directory before commiting, does
not work.
Now the same problem happened also to other projects, after I had to
change the content of the svn:ignore property to avoid that other files
are sent to the repository, and to subdirectories of the original project;
so avoiding to commit the top directory is not a good solution anymore.
I tried everything:
It is not possible to send the changes of the svn:property to the
repository, cleaning does help.
Is there a solution to the problem that is not dangerous for the integrity
of the subversion repository?
Thanks!
|
|
|
|
|
| Re: directory conflict because of svn:ignore [message #553350 is a reply to message #551824] |
Tue, 17 August 2010 04:56  |
| Eclipse User |
|
|
|
Hello,
this seems to be a tree conflict.
Let me try to explain in simple words: SVN cannot merge structural changes - so if you move a file to a new localtion and somebody else does a move to a different location of the same file this will not work. SVNs basic idea to avoid this to allow any kind of structural change only if the directories has the "latest" revision, so it is not "out of date".
Well, now that is for some reasons a general rule in SVN: you cannot change (=commit) anything changed in a directory when the directory is not the latest revision. This includes both structural changes and property changes of the directory.
So, lets think of a quite normal example. You have a project. You make an update of the project. Now you have the "latest" revision everywhere. Next you do an commit. Not those files that were part of the commit have a more recent revision, simply a higher revision number. Like this you get a mixed revision working copy.
As an commit in subversion is never an update this commit takes all directories that were not part of the commit in an "out of date" state - they are no longer present in the latest revision.
Now you want to change a property in one of those directories, e.g. the svn:ignore property of the root direkctory. Try to commit: error message - which is caused by the server and not by the svn client subversive or one of its components.
If you want more information on this please just google "svn tree conflict" or read the corrosponding part of the svn manual here: http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html
In short forms: Subversion will never destroy any user modification. So, from time to time just press the update button  and this will NOT overwrite your local changes like svn:ignore properties - and then commit!
One bad thing about subversive is that you cannot see whether you have a mixed revision working copy or not - the label decoration only shows the "last changed revision". This makes sence but from time to time you need the pure revision information as provided by subversion - I allready created an issue for this but it seems not to have enough priority. So, if you stay with subversive you will come into this problem from time to time - and if you change to subclipse you will have the same problem  .
Regards,
Olaf
|
|
|
Powered by
FUDForum. Page generated in 0.07753 seconds
Home