Simon Large wrote:
> I am just starting a description of the locking UI for the docs, and I
> have a couple of GUI queries.
> 
> 1. Should 'Get lock' be followed by '...' as there is a log entry dialog
> following?
Yes. Done in revision 3146.
> 2. Stealing and breaking locks seems too easy.
> The option to steal a lock is offered immediately. Should it appear only
> after an attempt to get a lock normally has failed, ie. Dialog stays
> open and 'Steal lock' is enabled for a second attempt? I know it will
> waste time if you already _know_ you need to steal a lock, but how often
> does that happen? The same could apply to 'Break lock', where it only
> appears in the context menu after a 'Release lock' has failed.
That would clutter the UI a lot. We'd have to keep the lock dialog open, 
check for any errors that might occur during the 'get lock' try. In case 
of an error related to a lock, we'd have to do what? Just enable the 
checkbox? User's won't notice that.
With 'break lock' appearing only if a 'release lock' has failed: that's 
not possible without a *major* hack. The context menu isn't linked 
against the full Subversion lib, and is completely independent of 
TortoiseProc doing all the work. So we'd have to find a way to pass that 
information to the shell extension part...
> 3. The lock status and error messages seem broken in places. I did this:
> 
> Lock Test.txt in WC1
> Break lock in WC2
> Check for (local) modifications in WC1 - initially correctly reports a
> lock
> Contact repository - incorrectly still reports a lock
That's how it should be!?
You locked the file in WC1
You broke the lock in WC2
You check for local mods in WC1 - you still see the broken lock
You contact the repository - you still see the lock in your wc
But I agree - we should show there that the lock isn't there anymore in 
the repository.
> Attempt to release lock in WC1 and get this error message:
>   Unlock failed: Test.txt
>   Error: No lock on path '/Test.txt' in filesystem 'c:/temp/Repos2/db'
>   Error: If you want to break the lock, use the "Check For Modifiations"
> dialog.
> 
> Line 3 (in this instance) should say something like:
>   Error: The lock has already been broken from within another working
> copy.
> 
> If the unlock failed because another WC holds the lock, you still want
> the original message, but there should be a 'c' in 'Modifications'.
Done in revision 3148.
Stefan
-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Apr 27 18:24:28 2005