Quoting "Eric W. Sink" <eric@sourcegear.com>:
> Anyway, we've spent a lot of time figuring out best to add locks
> to a design which is essentially identical to yours, so I thought
> perhaps my $.02 might be of value: We decided not to implement
> locks as a property on the object, and we have been very happy
> with that choice.
>
> Our server keeps a checkout list. Generally speaking, every file
> may have more than one user who has checked out that file. However,
> for non-mergable file types, and for situations where the user
> requested an exclusive lock, there is only one checkout allowed.
> But additions to this checkout list do *not* cause a bubble-up
> change to the repository.
>
> This works very well for us. We have to remind ourselves every
> now and then that the Checkout command does not alter the repository.
> However, that has seemed much better than the alternatives. We
> didn't want lots of checkout operations clogging up history.
> And we didn't like the idea that checkout occur within a
> transaction. Part of this falls out of our desire to preserve
> edit/merge/commit semantics for users who prefer that style,
> myself included. ;-)
Hear, hear! What I've been advocating all along (except for the checkout list on
the server, which is inappropriate for Subversion anyway).
> I think you still have a tricky decision on *if* you should
> include locks at all. It seemed clear to me that a compelling
> replacement for SourceSafe must have them, but it's not clear
> that compelling replacement for CVS should have them as well.
> Were Greg's "Excel use case" not so clearly valid, I would
> assert that they just don't belong in Subversion.
Oh, no, I don't see how that follows. We want to replace CVS, yes -- but that
just means we have to provide the functionality that CVS provides. It doesn't
meen we shouldn't provide more, where appropriate. Supporting both the
edit/merge/commit and lock/modify/unlock models is quite appropriate, and -- as
you've demonstrated -- can be done.
If nothing else, it'll allow the integration of subversion with all those
DAV-enabled clients out ther (MS Office, MSVC.NET, etc. etc.), which IMHO is a
compelling enough reason to eventually add locks.
> (I apologize if even this brief mention of Vault is considered
> inappropriate on this list.
Not at all.
> If anyone wants to ask questions
> about Vault, please keep it off this list and email me
> privately.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 10:46:28 2002