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