Currently (1.3.0-rc2) Subversion uses the same code to report entries for
update and status operation:
File is obstructed: file is reported as "deleted".
Directory is obstructed: reporter code fails with error.
For update that means that update will always fail to update obstructed
file, even when file (base version) actually doesn't need to be updated or
only its base version has to be update (when file is scheduled for
deletion). And obstructed directory completely disables update and status
Above behaviour is more or less correct, as obstruction is generally
something that have to be corrected before making update. However, this
behaviour is not correct (at least it may be more correct) in case of
"remote" status. I could see the following problems:
1. status -u file_obstructed_with_dir fails (though it doesn't fail for
unversioned or missing or scheduled for deletion file).
2. status -u for directory that includes file obstructed by directory will
report remote status for such file as "added". This is not correct if file
(base version) is up to date or when file is scheduled for deletion in the
working copy. From my point of view base version of the file should be
updated and update should notify user that working version of the file is
obstructed, but not stop the whole update procedure.
3. status -u for directory that includes child directory obstructed with
file will not work at all. I think it makes sense to report such directory
as "deleted" and receive remote status for it and its children as "added".
So, my suggestions are:
- report obstructed files as regular files. During update, update base
version of the file and additionally report "obstructed" status. Latter will
require API modifications, but first step could be easily done without
- instead of reporting error on attempt to report obstructed directory,
always report such directories as locally deleted. Update should either
fail, like it do now, or report obstruction as a warning and skip updates of
obstructed directory and its children.
- allow running status command against obstructed entries, like it is
possible to run status against missing entries or entries scheduled for
These changes will still make update to fail or report a warning message,
but will not prevent users from updating working copy that contains
obstructed entries and also remote status will reflect interrelation of the
wc state and repository better.
What do you think on that? Are there any undesirable side effects that
implementing my suggestions could result in?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Nov 10 22:46:48 2005