news <news@sea.gmane.org> wrote on 07/27/2006 06:08:19 PM:
> First I thought it was my mistake but now it looks like it's an issue in
> Subclipse because it happend a second time with a different project and
> a different repository (using JavaHL).
>
> Steps to repeat:
> 1. Share project that was never shared before
> 2. As part of the share process commit some files
> 3. Do some modifications (rename a file, set some ignores)
> 4. Invoke commit on the project
>
> Error:
>
> Merge conflict during commit
> svn: Commit failed (details follow):
> svn: Your file or directory '.' is probably out-of-date
> svn: The version resource does not correspond to the resource within the
> transaction. Either the requested version resource is out of date
> (needs to be updated), or the requested version resource is newer than
> the transaction root (restart the commit).
>
>
> To solve the issue:
> 1. Right click the project and update it
> 2. Commit again
That is not a bug, that is normal Subversion behavior that you solve
exactly as you indicated. Folders have versions too and those folders are
not advanced by committing a file in the folder. Consider the scenario
that you checkout a folder at r100. Someone else adds/deletes some files
and commits at r101. You now change a different file and commit it at
r102. Your folder is still at r100 because until you update the folder it
will not know about the adds/deletes that happened at r101.
Subversion does not allow you to rename/delete files or set properties on
a folder unless that folder is at its HEAD revision.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Jul 28 01:57:41 2006