Re: [Issue 533] New - implement reserved checkouts

Greg Stein speaks the truth:

> In any case: get out of the "source code" mindset. Think about other kinds
> of documents. Locking is required for almost any non-mergable file format.

Yes. The formats which are mergable with diff3/patch are a
very small subset of the ones people use. There are probably
other formats which would be mergable if we could invent new
merge tools, but that requires a level of imagination which is
hardly suitable for an argument against support for locks.

I'm mostly a lurker here, but I would like to contribute my
experience to the discussion of this issue. At SourceGear, we
are building a version control system as well. We call it
SourceGear Vault, and its design owes a great deal of inspiration
to the architecture of Subversion. Vault uses SQL Server instead
of Berkeley db and a .NET Web Services API instead of WebDAV.
But the architecture of the repository store is very similar.

The other major difference: Whereas Subversion is to be a compelling
replacement for CVS, Vault is to be a compelling replacement for
SourceSafe. As such, it was essential that we offer locks.

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. ;-)

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.

(I apologize if even this brief mention of Vault is considered
inappropriate on this list. If anyone wants to ask questions
about Vault, please keep it off this list and email me
privately.)

--
Eric W. Sink
Software Craftsman
eric@sourcegear.com
----- Original Message -----
From: "Greg Stein" <gstein@lyra.org>
To: <dev@subversion.tigris.org>
Sent: Monday, August 05, 2002 3:27 AM
Subject: Re: [Issue 533] New - implement reserved checkouts
> Oh, geez. This whole thread is way too narrowly scoped. *Everybody* is
> talking about developers and source code. Fine, geez. No locks.
>
> Now talk to me about .doc files.
>
> On Fri, Aug 02, 2002 at 05:33:19PM -0500, Jim Blandy wrote:
> >...
> > I'd like to hear more about people's real-life situations, more at the
> > ``project manager looking for good working procedures'' level, and
>
> At CollabNet, we have a big-ass Excel spreadsheet that contains the
feature
> matrix for our upcoming releases. We use it to list out the desired
> features, who requested them, what priority we feel it is [for those
> customers], what release we're going to put it into, etc.
>
> Fact: Excel spreadsheets are non-mergable.
> Fact: there is only *one* instance of this .xls file; forking is not
>       acceptable
>
> We had about three people attempting to work on the thing. For the most
> part, we flowed all the change requests through one guy. But every now and
> then, we'd get this email to the Tech Managers mailing list, "hey, I want
to
> edit the feature matrix? anybody else working on it?" And *everybody*
would
> have to email back "nope. go ahead" before the first person felt it was
> safe. If Joe Random was out of the office, and didn't reply, but had a
> buttload of changes. Oops. We'd be screwed.
>
> Advisory or mandatory locks are pretty well required in this situation.
You
> would know right off the bat that somebody else is working on it, and you
> can't touch it. You can certainly go and ask the person when they'll be
done
> with it, and you can possibly be a prick and break their lock. But that
> simple bit avoids annoying posts to the mailing list, and the requisite
> replies back.
>
> I think the difference between advisory and mandatory is mostly about how
> screwed you would be if people misbehaved. Is there *any* way to derive
each
> person's changes and get them merged into a final document? If the answer
is
> a resounding no, then you apply hard-ass mandatory locks. Somebody better
> have a darned good reason for breaking the lock (but yes: you always allow
> somebody to break it).
>
>
> In any case: get out of the "source code" mindset. Think about other kinds
> of documents. Locking is required for almost any non-mergable file format.
> Karl likes to say "but communication solves all that". It sure does, but
the
> amount of communication necessary is hella more painful than a flag bit.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org