Stefan Sperling <stsp_at_elego.de> writes:
> On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote:
>> The situation is as follows (the minimum necessary to reproduce the issue):
>> - have a working copy with a folder and a file inside the folder;
>> - replace the folder and commit:
>> svn delete folder/file
>> svn delete --keep-local folder
>> svn add folder (consider it as a new folder)
>> svn commit folder (both folder and file)
>> make new "file" inside folder
>> svn add folder/file
>> svn commit folder/file
>>
>> - now, in another working copy:
>> svn status -u - reports folder as replaced and file
>> as deleted
>> svn update folder/file - svn indicates that file was updated fine
>> svn statsus -u - again, both folder and file are
>> reported as previously (replaced and deleted)
>>
>> Repeating the file update and "svn status" goes on and on as
>> file updated correctly and file reported as deleted again.
>>
>> Only after updating the folder everything works fine.
>>
>> My question(s):
>> - is this OK to happen like this?
>
> Yes, absolutely. The 'svn update folder/file' step creates a
> mixed-revision working copy (child is newer than its parent)
> and you then query the parent with 'status -u' so you get
> results for the parent, not the child.
It's a bit more complicated than just mixed-revision in this case; the
status display is affected by internal implementation details of the
update process. The tricky bit is that the parent directory is going to
be deleted and replaced and the update process will delete the children
inside the parent even though those children are already up-to-date.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-09-30 15:35:50 CEST