Re: Reporting of obstructed entires.

You've taken a great deal of care to write out these recipes in
precise English, thanks. But I'd still find these problems easier to
understand if there were a reproduction script -- I can't always be
sure I'm understanding the prose description correctly. (I don't know
if anyone else agrees with me, but I noticed there were no other
responses...)

Best,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
"Alexander Kitaev" <alex@tmate.org> writes:
> Hello All,
> 
> 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
> operations. 
> 
> 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
> significant modifications.
> 
> - 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
> deletion. 
> 
> 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?
> 
> Alexander Kitaev,
> TMate Software,
> http://tmate.org/
> http://jetbrains.com/tmate/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org