Re: [Locking] commits and unlock (revisited)

Brian W. Fitzpatrick wrote:
> 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.

Or rather, "Helps to avoid you forgetting ..."

Also: - Simplifies working with locked files if you rarely need to
             make multiple commits without releasing a lock.

> 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

Not just 'some' locked files at random, but precisely those TARGETS that
(because they are modified) actually get committed.

> PROS: - Makes it easier to divide separate commits into changesets.
>
> CONS: - YASSC (Yet Another Subversion Special Case).
> - Violates KISS.

Also: - If you want to make multiple commits to a file without
             releasing a lock, you need to pass --no-unlock when
             committing.

>
> c) Upon commit, unlock nothing
>
> PROS: - Avoids possible conflicts in unmergeable files that are left
> unlocked (although svn:needs-lock alleviates this somewhat).

I don't understand that point. Please elaborate.

> - Doesn't overload commit with locking behaviors.
>
> CONS: - You can forget that they you have files locked and prevent
> others from editing those files.

Also: - If you want to unlock a file when you commit it, you need
             to pass --unlock when committing, or use a separate command.

- Julian

---------------------------------------------------------------------
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:00:26 2005