Edward Harvey wrote:
>
>
>> The problem is that changing a property requires a commit, so
>> using such a method would mean 1 extra commit to set the
>> needs lock, and all the handling to go around that. Then if
>> you release a lock without commiting, it has to unset the
>> needs-lock with another commit again.
>
> Ok, How does this sound --
>
> If a person clicks "get lock" on a file that doesn't have "needs-lock,"
> then...
> - During the "get lock" dialog, display a checkbox (selected by
> default) to also set "needs-lock."
> - If the person leaves this checkbox selected and hits OK, then...
> - Set the needs-lock property.
> - Commit
> - Get Lock.
> - If the person clears the checkbox and hits OK, then...
> - Just get lock. (doesn't make any sense, but what can you do...)
>
> If a person clicks on "release lock," and the file has "needs-lock" then...
> - Display a choice:
> - " Remove the needs-lock property" or "Nobody can edit without a
> new lock"
> - Present a checkbox to save this decision for future times of
> "release lock"
> - If the person chooses " Remove the needs-lock property" then...
> - Remove the needs-lock property
> - Commit
> - Release lock
> - If the person chooses "Nobody can edit without a new lock" then...
> - Release lock, but keep the needs-lock property .
>
> Does this sound reasonable to everyone?
Absolutely not. By even providing such an option it makes it appear to
the user that this is a reasonable thing to do, whereas in fact it is
only reasonable if you are absolutely determined to crowbar subversion
into a way of working for which it was never designed.
There might possibly be some sense in having the option to add the
svn:needs-lock property, but I much prefer Hans-Emil's solution of
showing a warning icon when you go to get a lock. Composite actions such
as this are not encouraged as Hans-Emil has already said.
Having an option to remove the property makes no sense at all except in
your particular use case which, as has been said ad nauseam, is not the
way subversion works. This is definitely not an option we would want to
make easier because it would make it very easy to remove the protection
that svn:needs-lock offers. If a group decides they want to use the
lock-modify-unlock method, and someone checks that box by mistake, the
protection they thought they had silently disappears, and no-one else
will know about it unless they happen to notice the icons behaving
differently.
Simon
--
___
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 Fri Apr 28 10:38:52 2006