Re: [Issue 533] New - implement reserved checkouts
From: Eric W. Sink <eric_at_sourcegear.com>
Date: 2002-08-05 15:33:22 CEST
Greg Stein speaks the truth:
> In any case: get out of the "source code" mindset. Think about other kinds
Yes. The formats which are mergable with diff3/patch are a
I'm mostly a lurker here, but I would like to contribute my
The other major difference: Whereas Subversion is to be a compelling
Anyway, we've spent a lot of time figuring out best to add locks
Our server keeps a checkout list. Generally speaking, every file
This works very well for us. We have to remind ourselves every
I think you still have a tricky decision on *if* you should
(I apologize if even this brief mention of Vault is considered
-- 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.orgReceived on Mon Aug 5 15:37:51 2002 |
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.