Edward Harvey wrote:
>> What about a policy "aquire a lock if you don't know if
>> anybody is working on that file"?
>
> It is absolutely possible for me to tell users to follow a rule. They
> might even follow the rule most of the time. But computers are better
> than users when it comes to automatically following a rule. Especially
> if the rule would mean more mouse clicks for the user.
>
> I think the user experience would be better, if they could already see
> that someone had obtained a lock, with merely a glance down the list of
> files, instead of having to perform some mouse clicks to find out.
>
> If a user is going to work on a file, sometimes he/she wants to obtain a
> lock, knowing he/she will probably work for a long time on this file.
> But if he/she is only going to change one line, for example, create a
> new flag variable within a class, they would rather just make the change
> and commit. Nevermind get lock and release lock.
>
> So although a policy of globally "needs lock" does in fact force users
> to always check for lock before modifying a file, I'm sure some users
> would prefer to have some of the checking work done for them, rather
> than forcing them to do a little more work themselves.
You need to decide which model you are using and stick with it. Our
manual describes the Lock-Modify-Unlock model used by VSS and others,
and the Copy-Modify-Merge solution used by CVS and others. SVN supports
both models, although it favours the latter for 'mergeable' files.
If you are working with text files, the copy-modify-merge model works
very well and there is no need for locking at all. 2 users can work on
the same file, although they do need to communicate so as not to work on
the same parts of the file at once. No extra mouse clicks, and no-one
gets locked out.
If your workers do not like this model, or do not bother to communicate,
then you can fall back to a full locking model, but you must also use
the svn:needs-lock property to make it work. Locking alone offers you no
protection against wasted effort.
If you are working with binary files, merging is impossible and the full
locking model is highly recommended.
Subversion and TortoiseSVN are open source projects and neither of them
uses locking. The copy-modify-merge solution really does work.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Apr 26 01:25:12 2006