Brian W. Fitzpatrick wrote:
>I'd like to revisit the decision that came out of the "commit and
>unlock" discussion in December (Full thread here
>The outcome of that thread was that 'svn commit' will unlock any file
>that is specified as a target to 'svn commit' (including children of
>I've read through the thread, and I can't say that I saw a clear
>comparison of the pros and cons of the various options presented, so
>I'd like to open up this can of worms again and do some "information
>gathering and aggregation."
>The three options for *default* behavior that were presented are:
> a) Upon commit, unlock all locked files in TARGETS
> PROS: - Helps when you forget to unlock files when you're done with
- Every other VC system I know does this by defauls.
> CONS: - If you want to make multiple commits to a file without
> releasing a lock, you need to pass --no-unlock when
> 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.
- YASSC obtains here, too.
>Can interested parties please contribute more pros and cons to this
>list? I'll summarize the discussion and post the total pros and cons
>to the list.
>PS: I'm in favor of C.
I can't imagine why. The user has _already_ taken the time to list all
the targets, and has either completed a change (which means that
atomically unlocking the files is the Thing To Do), or is making a
checkpoint commit, in which case she says --no-unlock. Of course a)
assumes that if the commit fails, locks aren't affected.
I think forgetting to unlock after a commit is a huge enough problem to
make c) lose in any comparison with a) unless we find some very, very
compelling reason why a) whould be undesirable.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Feb 22 22:50:59 2005