Norbert Unterberg <nunterberg@gmail.com> writes:
> * The manual states that locks are released on files during a commit,
> even if the files are unchanged. But this failes if no file has been
> changed at all. So if I commit my working folder with file1.txt
> changed, the lock on file2.txt is released. If I commit with no file
> changed, file2.txt remains locked. I am not sure if this is intuitive.
It is intuitive in some circumstances, and not in others. The rule
is, if a commit actually happens, the locks are released. Since no
commit happens when no files are modified, no locks are released.
> * It is quite difficult to detect what files are locked by whom. There
> is no direct counterpart to "cvs editors". You need to provide the
> complete URL of each single file to get the lock owner. No way to
> specify wild cards. No way to just use the local filename. How about
> something like svn info file2.txt --remote to save the user from
> typing the long url? Or how about a svn status --show-lock-owners?
> Even svn status -u does not show the lock owners.
You're right. But, it's a very complex UI issue. What exactly do we
want to show? Say we make 'svn info -v' show the union of local and
remote information -- then how would it represent a file that is
locked remotely, but not locked locally (because out of date), or for
which for some other reason you don't locally have the lock token?
Maybe the right course is to not overload 'svn info', but instead have
a dedicated command just for showing locks. But then should it be a
port of 'svnadmin lslocks' to the command-line client, or should it be
a new flag, like 'svn lock --show', or something else?
None of these are insurmountable difficulties. What is required is
someone willing to spend some serious time & concentration on the
problem -- someone who will initiate a design discussion, play "honest
broker" during it, narrow things down to a few viable proposals, etc,
etc. So far, no one has had time to do this. If you do, though, that
would be great! Just post to dev@ and start it off. Or if not,
eventually someone else will get around to it, but I can't say when.
Implementation is not going to be difficult here. Choosing the right
UI is what's going to be hard.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 23:13:33 2005