Hello Karl,
Thanks for taking time to answer my letter!
The following use cases demonstrate the problem:
Test fixture:
- create a file (file3.txt in my example).
- and and commit created file
- schedule file for deletion (working file will be deleted)
- create a directory with the same name as a deleted file.
1) Subversion fails to report local status for obstructed file (remote
status is reported properly):
C:\wc4\dir>svn st -v .
280 280 ? .
~ 280 278 ? file3.txt
280 280 ? dir.txt
C:\wc4\dir>svn st -v file3.txt
svn: Working copy 'file3.txt' is missing or not locked
2) Subversion reports incorrect remote status for obstructed file:
// this works properly (file3.txt is reported as regular file).
C:\wc4\dir>svn st -vu file3.txt
~ 280 278 ? file3.txt
Status against revision: 283
// this doesn't work properly (different reporter code is used and file3.txt
is reported as "deleted").
C:\wc4\dir>svn st -vu .
~ * 280 278 ? file3.txt
280 280 ? dir.txt
280 280 ? .
Status against revision: 283
Notice that file3.txt in status output is marked as having incoming changes.
This kind of status is reported because osbstructed files are reported as
"deleted" (with reporter->deletePath(...) function).
My suggestion is to report obstructed files as regular files, this will fix
the above problem with remote status.
3) Subversion doesn't allow to run "remote" status when directory is
obstructed with file (dir.txt is obstructed with a file):
// local status works properly:
C:\wc4\dir>svn st -v dir.txt
~ ? ? ? dir.txt
C:\wc4\dir>svn st -v .
280 280 ? .
~ 280 278 ? file3.txt
~ ? ? ? dir.txt
// remote status (and update) always fails.
C:\nautilus\svn\deleted\wc4\dir>svn st -vu dir.txt
svn: The entry 'dir.txt' is no longer a directory; remove the entry before
updating
C:\nautilus\svn\deleted\wc4\dir>svn st -vu .
svn: The entry 'dir.txt' is no longer a directory; remove the entry before
updating
To fix this problem I suggest to report obstructed directories as "deleted"
locally, so that remote status will report directory as "incoming addition".
Update operation should also handle "obstructions" at the moment of update,
not at the moment of reporting wc state.
Hope above examples will help.
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: kfogel@newton.ch.collab.net
> [mailto:kfogel@newton.ch.collab.net] On Behalf Of kfogel@collab.net
> Sent: Saturday, November 12, 2005 06:45
> To: alex@tmate.org
> Cc: 'Svn Dev'
> Subject: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 17:37:39 2005