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
Received on 2013-09-30 10:03:55 CEST