Greg Hudson wrote:
>What we can do is alter our behavior on a conflict for a file which
>has been tagged with the svn:lock property. Instead of generating a
>conflict marker and perhaps attempting a merge, we can leave the local
>edit in place, drop the repository edit into a backup file, and warn
>the user. I'm not certain whether this is right or not.
>
>
I think svn should behave exactly as with "normal" conflicts, _except_
that it should not try to merge changes into the working copy --
regardless of whether the working copy has actually changed from BASE.
For UI purposes, we could show an H(ijack) instead of a C(onflict), but
the same information may well be conveyed by "svn st" marking the file
as locked in the WC.
>As you all know, I've very keen on keeping our command set small.
>"svn lock" and "svn unlock" are pretty much non-negotiable for this
>feature, but when we already have "svn status" and "svn info", do we
>really need a separate "svn lockinfo"? I realize that svn info is a
>client-local operation and lock information has to be fetched from the
>server, but perhaps this could be an option to "svn info".
>
>
Obviously both "svn info" and "svn st" must show a certain amount of
lock information. There's no reason why "svn info" shouldn't optionally
contact the server (with -u) or work with URLs. In fact "svn st" could
work with URLs, too, and suddenly "svn info" becomes another way of
spelling "svn status --very-verbose" :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 01:00:25 2004