[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Locking] commits and unlock (revisited)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-02-22 23:06:04 CET

"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.

   (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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.