Strange behavior after replacing directory

[Florin Avram <fl...@sync.ro>]

Hi,

I've found a strange behavior in the situation described below and 
wanted to let you know - I think there could be an issue or a need of 
improvement (don't know what exactly).
Subversion: 1.8.x, 1.7.x.

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? My colleagues started to be confused 
since they saw the file exists in the repository, but it was reported as 
DELETED in the working copy and an "svn update" seemed to work until 
checking again if there are other changes in the working copy;
- if "svn update" should work, then there is an issue, because the file 
is reported back as DELETED on an "svn status -u".
- if it is correct not to work, because of the dependency between the 
file and the parent dir being replaced, at least should provide a 
meaningful message to upgrade the parent also. Or at least it should 
skip the item, like in the case when a directory is added and you try to 
update only one of its children.

Can you tell if this is the correct behavior or this is an issue?!

Thank you,
Florin

Re: Strange behavior after replacing directory

[Florin Avram <fl...@sync.ro>]

Hi,

Thank you for the quick reply.

Strange thing. I was expecting that the repository will notify me only 
about the items/revisions/changes I am missing. If the update of the 
file was successful, then when "svn status -u folder", the repository 
should report that only the folder has changes (it was replaced), but 
the file is already updated. Somehow, this can be misleading, even more 
if users are not very SVN-experimented.

Best Regards,
Florin


On 30.09.2013 12:54, Stefan Sperling wrote:
> On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote:
>> Hi,
>>
>> I've found a strange behavior in the situation described below and
>> wanted to let you know - I think there could be an issue or a need
>> of improvement (don't know what exactly).
>> Subversion: 1.8.x, 1.7.x.
>>
>> 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.
>
> See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
>

Re: Strange behavior after replacing directory

[Philip Martin <ph...@wandisco.com>]

Stefan Sperling <st...@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*

Re: Strange behavior after replacing directory

[Stefan Sperling <st...@elego.de>]

On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote:
> Hi,
> 
> I've found a strange behavior in the situation described below and
> wanted to let you know - I think there could be an issue or a need
> of improvement (don't know what exactly).
> Subversion: 1.8.x, 1.7.x.
> 
> 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.

See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs