Re: [Issue 533] New - implement reserved checkouts

  Jim Blandy wrote:

>brane@xbc.nu writes:
>
>
>>Hear, hear! What I've been advocating all along (except for the
>>checkout list on the server, which is inappropriate for Subversion
>>anyway).
>>
>>
>
>Could you spell out exactly what you've been advocating all along?
>I'm having trouble piecing people's positions together, partially due
>to the rash of misunderstandings on this topic.
>
>

O.K., lemme try to remember ... :-)

   1. A lock must not create a new revision.

   2. It must be possible to lock non-HEAD revisions, so that branches
      can't be made from them.

   3. Locks must be mandatory in the sense that a non-owner can't
      accidentally commit a change to a locked resource.

   4. There should be an easy way to list locks (without checking out a
      WC), and their associated template log messages. By implication,
      the default log message for a lock-releasing commit should be
      gleaned from the locks' template log messages.

   5. (Bonus points) It would be nice if several locks could be released
      in a single commit. For example, if you're editing two related
      files, and have locked each one separetely, but commit both at
      once, the commit and lock release should be atomic. this implies
      that, if locking internally creates a long-lived FS transaction,
      it should be possible to associate several locks with the same
      transaction.

The thing I still haven't cleared up in my head is this: if the same
node is visible as A/B and X/Y, and you "svn lock" A/B, does that mean
X/Y is locked, too? Both models have their pros and cons. Have to think
a bit deeper about that.

A related question is, does locking affect bubble-up directories? In
other words, does locking the root of the repository prevent any changes
to the repo, or just modifying entries in the root?

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org