[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 533] New - implement reserved checkouts

From: <brane_at_xbc.nu>
Date: 2002-08-06 11:00:57 CEST

Quoting Karl Fogel <kfogel@newton.ch.collab.net>:

> I meant that Subversion itself should provide the communication
> mechanism, because it can do a much better job than email, phones, and
> smoke puffs. And if it does provide that mechanism, it has solved the
> same problems that locking solves, but without getting in people's way
> as much as locking.
>
> By "better", I mean specificially that Subversion can store and
> deliver messages about who wants to exclusively work on what, and
> deliver them in a timely fashion, because everyone's already using the
> revision control system to get information about the files. They're
> not using their mailreaders or telephones to update their files --
> that's why it's a pain to use those channels to obtain locking
> information.

At the risk of being boring, I'll (again) describe how ClearCase does this: It
asks for a commit log message at _checkout_ time, i.e., when you lock a file or
directory. That message is visible to other users, and serves as the template
for the "real" log message at commit time.

Another thing: In ClearCase, you have both reserved and unreserved checkouts
(call them strict and advisory locks, if you like). Only one user can hold a
strict lock on an object, but any number can hold an advisory lock. While they
can't commit until the strict lock is removed, they can still signal their
intentions (by way of the log message) and later promote the advisory lock to
strict, if necessary.

> So when I say "it's about communication", I don't mean the usual
> generic thing ("Developers should talk to each other" and all that).
> I mean something technical that we can provide.

I suspect ClearCase accomplishes exactly what you were talking about. I wouldn't
mind if we did something similar in Subversion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 11:01:34 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.