[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: Branko Čibej <brane_at_xbc.nu>
Date: 2005-02-22 22:49:16 CET

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
>http://svn.haxx.se/dev/archive-2004-12/0598.shtml).
>
>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
>directories).
>
>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
> them.
>
>
- 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
> 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.
>
>
- 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.
>
>-Fitz
>
>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.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 22:50: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.