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. And "Steal All" is something I wouldn't do. Remember:
stealing a lock is like creating a conflict!
> 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.
>>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:
- 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.
- 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.
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.
Imagine the following:
- file is locked by user 'joe'
- user 'mike' wants to edit that file
- the file is read only
- user 'mike' can't edit the file
- 'mike' thinks about why, finds out that the file is locked.
- hmmm, he want's to edit the file, so he has to get the lock on that
file to do that.
- 'get lock' will fail, because it already is locked.
- user 'mike' then sees that there's an option to steal the lock, which
is what TSVN tells him to do if a lock fails.
- user 'mike' steals the lock
- 'mike' happily edits the file without even realizing that he's done
something very bad for the one owning the lock previously.
So: both stealing and breaking locks should *not* be easily accessible.
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 Sat Apr 9 18:41:46 2005