SteveKing wrote:
> Molle Bestefich wrote:
>
> > Sounds like a good way to do it. But it seems overly complex.
> > For starters, I think we should just do what so many other
> > applications have done before: Steve's suggestion #3, with a slight
> > tweak:
> >
> > - There should be "Steal All" and "Skip All" buttons.
> > - There should be a "Cancel" button.
>
> Too many buttons.
Nah, TSVN users can cope with 4 buttons and a text.
> And "Steal All" is something I wouldn't do. Remember:
> stealing a lock is like creating a conflict!
You're right, that's not a good thing.
> > Although this solution is simple to implement and thus will get
> > locking into TSVN and out to users faster ;-), there's a slight edge
> > case with it: the "Skip All" option. If TSVN is told to auto-skip
> > half of a bunch of files, how does a user know which files was
> > actually locked? It warrants for new lock overlay icons, or a status
> > dialog at the end of the operation. Not sure if this is important.
>
> I'm not sure what the "skip all" button really would do - if you skip
> every lock, then that's like doing nothing.
"Of all the files one is trying to lock, only lock the ones that are
not locked by others." That's what it would do.
> >> For better or worse, those are the terms agreed upon by the Subversion
> >> devs, so I doubt TSVN would want to invent its own conventions.
> >
> > On the contrary. It's a technical term for what the Subversion
> > backend actually does; we should use terms that relate to what the
> > users are trying to do with that technical feature. I don't see any
> > problem with using a different wording. Other versioning systems
> > actually prohibits the user from changing local files if they have not
> > "acquired it for writing", eg. locked it, this is not the case for
> > Subversion. We definitely should be careful with the wording, and we
> > SHOULD use different terms than lock/unlock.
>
> A different wording is not a good idea. Many users use both TSVN and the
> CL client. The subversion book relates to the CL client. So users
> reading the docs will be familiar with 'lock' and 'unlock' and therefore
> look for the same commands in TSVN too.
>
> So, I have something implemented already. I will change it of course if
> there's a better solution. But for the time being, I'll leave it that
> way because I need something that works to test the locking features in
> TSVN. Here's what I did:
If you're going to implement it and not bother to change it, why are
you even asking for ideas...
> - right-click on non-locked files --> 'get lock' menu. Dialog pops up
> where the user can enter a lock message. The dialog also has a checkbox
> (unchecked by default) which reads 'steal lock' and would attempt to
> steal already existing locks.
Exactly as Evil as the "Steal All" button you declined yourself. It
should only be possible to steal a lock consciously, after having been
given a notification about who has it, for how long it's been had
(since last commit), and such.
> - right-click on locked files --> 'get lock' menu and 'release lock'
> menu. The 'get lock' is of course the same as above. The 'release lock'
> will attempt to release the lock (unlock). If that unlocking fails, the
> error message is shown why it failed. Then a hint text is added to the
> error message telling the user that for breaking those locks, a
> SHIFT-right-click is needed on those files. If that's done, the 'release
> lock' menu is changed to 'break lock' to indicate the action to be done.
It's overly complex for ordinary users, and it's creepy UI design to
change a context menu if you hold down SHIFT while right-clicking it..
> On a sidenote: we shouldn't make it too easy for users to break or steal
> locks. Doing that wil almost every time lead to a conflict. And the
> conflict will occur for those who had the locks in the first place, not
> the ones stealing/breaking them.
That's an important point, not a sidenote.
It may be such an important point that it's OK to hide the option in
an extremely annoying place, like you've done in the shift-right click
fashion mentioned above.
Anyway, the semantics of the menu entries are a moot point.
I've told what I think is way more important in my previous posting :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 18:55:55 2005