sussman@gmail.com wrote on 01/04/2006 11:50:30 AM:
> I think this is a big usability weakness in our UI. We need something
> better.
>
> The irony is that we *already* have a single RA command to "fetch all
> locks below a repository path". We even have an example program
> (tools/examples/getlocks_test.c) which demonstrates it.
>
> For now, I think I'm going to build the getlocks_test binary on OS X
> and just give it to this team to use as a workaround. But I'd love to
> hear ideas about how to make the commandline client itself more
> usable. (For GUI tools like TSVN, I imagine some sort of "locks
> report" would be a nice thing to add.)
>
> Thoughts?
Users on the TSVN and Subclipse mailing lists have frequently requested
decorators to show that someone has a file locked. To do this, that
information has to be cached in the WC. This idea has always been
rejected by the devs based on the argument that it would almost alwys be
stale info. Given the choice, as well as possibly an option to refresh
the information, some of these users have said they would prefer it.
I have mixed feelings. When you try to lock a file, it will fail and tell
you who has it locked. Why did I really need to see this info before
attempting to lock the file? What difference would it have made?
What if svn info, when run on a local WC file, had an option to get the
latest server information? This could then show you the current lock
information from the repository, as well as if the file were out of date.
GUI's could possibly use this as a way to provide an option users could
use to check the information for a file before locking it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 4 18:07:03 2006