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

Reply via email to