Bruce DeVisser wrote [12/17/04 12:40 AM]:
> [...]
> Perhaps I have a difference viewpoint because I work in an
> environment where locking is enforced. Developers have
> non-trivial work to do on multiple files, and typically the
> scope of work is known ahead of time (eg, 15 files +/- will
> need to be changed by one developer over the course of days
> or even weeks), but not committed all at once. The files are
> locked by the developer when we starts; the work
> proceeds by degrees, with changes committed periodically
> (files are left locked); and then finally, when the whole
> 'chunk' of work is done, the files are all unlocked. This
> may not be the use case in front of the Subversion
> development team daily, but it is out there.
>
> Here is how I envision the two options functioning in our
> typical development scenario at work. This disregards
> command-line switches or user configuration to supersede
> default operation; the concern is strictly with 'what makes
> sense for a default'.
>
>
> Option A: unlock on checkin:
> 1. Work sequence
> svn lock file1 ... file15
>
> <edit some>
> svn ci file1 file2 file3
> svn lock file1 file2 file3
> <edit some>
> svn ci file2 file4 file6 file8 file10
> svn lock file2 file4 file6 file8 file10
> <edit some>
> svn ci file3 file5 file6 file8
> svn lock file3 file5 file6 file8
> ...
> svn unlock
>
> 2. Note that 'svn ci' is never applicable, because it will
> clear the locks, necessitating another long unlock
> command. Also note that the locks are released for a
> moment after every checkin.
>
>
> Option B: no unlock on checkin
> 1. Work sequence
> svn lock file1 ... file15
>
> <edit some>
> svn ci
> <edit some>
> svn ci
> <edit some>
> svn ci [occasionally file list may be needed]
> ...
> svn unlock
>
> 2. There is a reason 'svn ci' and friends are recursive by
> default: it makes things easier for the user. Clearly,
> not auto-locking on checkin is the only way to retain
> this benefit in this use-case.
>
>
> Granted, there are use cases wherein it would be nice to
> clear all the locks upon commit. But if that doesn't happen,
> the remedy is simple: just an extra 'svn unlock'. Compare
> that to the nuisance auto-clearing of locks inflicts on the
> use case I've described above, and the choice is clear.
>
> Furthermore, the defaults in Subversion have always tended
> on the side of safety. While there is, strictly speaking, no
> safety issue here (the local working copy is not lost), the
> consequences of forgetting a '--no-unlock' switch are
> potentially more serious than those of forgetting a
> '--release-locks' switch in terms of trying to reconcile
> concurrent updates.
>
> I truly believe that Ben's original line of reasoning was,
> and continues to be, both valid and persuasive: locking and
> committing are orthogonal operations. Checking in a file
> does not imply that you want to unlock it; frequently it is
> not the case.
>
> Bruce
Thank you. You have eloquently expressed what I fumblingly was trying to
get at in part of my message much earlier on this thread.
Shawn Harrison
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 3 20:33:59 2005