"Brian W. Fitzpatrick" <fitz@collab.net> writes:
> a) Upon commit, unlock all locked files in TARGETS
>
> PROS: - Helps when you forget to unlock files when you're done with
> them.
>
> CONS: - If you want to make multiple commits to a file without
> releasing a lock, you need to pass --no-unlock when
> committing.
>
> b) Upon commit, unlock SOME locked files in TARGETS
>
> PROS: - Makes it easier to divide separate commits into changesets.
>
> CONS: - YASSC (Yet Another Subversion Special Case).
> - Violates KISS.
>
> c) Upon commit, unlock nothing
>
> PROS: - Avoids possible conflicts in unmergeable files that are left
> unlocked (although svn:needs-lock alleviates this somewhat).
> - Doesn't overload commit with locking behaviors.
>
> CONS: - You can forget that they you have files locked and prevent
> others from editing those files.
I find that (a) and (c) are perfect (enough) opposites, and trust that
regardless, there will be a configuration option to toggle between
those two states. (b) is just flatly insane -- whack-o behavior that
requires yet another Book paragraph to describe.
So, I could either way for (a) or (c), and will fall back to (a) as
choice because VSS (the VC system whose locking model I believe we
most want to be compatible with, if any) does things this way.
So:
(a) +1
(b) -0.9999
(c) +0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 23:08:59 2005