Thank you, Team -> Update helped.
But it still seems a
counter-intuitive property of SVN that I have
to update my project
even if I am the only person who has changed it.
This is how I
have understood it from the Subclipse FAQ and the
Subversion
book:
Suppose that I check out a directory A (let's say it is at
revision 10).
Suppose that directory A contains a file B (which is
also at revision
10, since directory A is up-to-date after checkout).
Also suppose that
I am the only person who makes changes in this
directory since revision
10. If I modify file B and commit directory
A then file B goes to the
new HEAD revision (let it be 15) but
directory A remains at revision 10,
since svn commit only commits the
modification of file B and does not
check whether the some files have
been added to directory A or whether
the properties of directory A
have been modified between revisions 10
and 15. On the other hand,
the revision number of directory
A in the repository becomes 15 as
its contents changed. Let's
say that I now want to delete directory A
from the repository. If I
try to commit the deletion of directory A
then svn commit says that my
working copy of directory A is
out-of-date and won't proceed and I need
to update directory A prior
to committing its deletion.
It is reasonable that one cannot
commit the deletion of a directory that
has some changes that one has
not seen. In this case, however, svn
update to directory A would do
nothing but change the revision number
of the working copy of A from
10 to 15 since all the files it contains
are up-to-date, no adds or
deletes have been made to A between
versions 10 and 15, and the
properties of directory A have not
been changed between the revisions
10 and 15.
So I think that when I try to commit the deletion of
directory A in the
situation I described then the svn client could
check whether directory
A is actually up-to-date (regardless of the
fact the revision number of
its working copy is 10), i.e. whether
update would actually do anything
more than just increase the
revision number of directory A, and if it
turns out that directory A
is virtually up-to-date then its deletion
should be
committed.
Or another option would be that when I commit file B
then its is
checked whether the copy of directory A in the repository
has been
changed since revision 10 and if not, then the svn client
would update
the revision number the working copy of directory A to
15 as well. If
there have been some changes to directory A between
revisions 10 and 15
then these changes should not be checked out, of
course, and the
revision number of the working copy of A should
remain 10. If there are
more parent directories of B under version
control than just directory
A, then all this would apply to all these
parent directories, too.
Jaan
>On 12/15/06, Jaan
Vajakas wrote:
>> Suppose I have a project
with a package named aa.bb under SVN version
>> control. If I
rename the package aa.bb to aa.cc in Eclipse by
right-clicking
>> the package name in Package Explorer ->
Refactor -> Rename... and after that
>> if I try to commit
the project (by right-clicking the project name in
>> Package
Explorer -> Team -> Commit... ) then I get an error message
box:
>> "org.tigris.subversion.javahl.ClientException: Item
is
>> out-of-date
>> svn: Commit failed (details
follow):
>> svn: Item '[...]/aa/bb' is out of date"
>>
It seems that Eclipse package name refactoring does not handle correctly
the
>> SVN data in the package folder and as a result,
Subclipse fails to delete
>> the old package directory from the
repository. Can this bug be fixed?
>> I am using the latest
Eclipse (3.2.1) and Subversion (1.1.9) under Windows
>>
2000.
>
>You just need to run Team -> Update prior to the
commit. See this
FAQ:
>
>http://subclipse.tigris.org/faq.html#out-of-date
>
>Mark
------------------------------
Telli Päevaleht ja võida 4 Nissani maasturit!
http://www.epl.ee/4x4
Received on Sat Dec 16 12:07:01 2006