On 2 Aug 2002, Jim Blandy <jimb@red-bean.com> 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
> less at the ``Subversion implementor'' level.
I've recently had the pleasure of using ClearCase at work, and let me
tell you it makes me feel like going straight home and trying to help
Subversion. :-)
I don't know very much about the internals, but I do have some
observations on the user experience. I guess beforehand I should say
that I hear most teams using ClearCase tend to build complicated
script layers on top, and so it may work differently in other
environments. My impression is that we're using it more or less
bareback.
ClearCase views are by default read-only; you must checkout (~= "cvs
edit") any file to be able to modify it. I think this behaviour is
the same as SCCS, Perforce, and Bitkeeper, and it's kind of like RCS
if you keep things unlocked by default. One effect is that if
somebody checked in a file like config.status and you try to modify
it, then you get a warning straight away, rather than noticing it when
you go to check in.
When you check out a file, you can make either a reserved (the
default) or unreserved checkout.
"Reserved" means, more or less, that you are guaranteed the right to
create the successor to that version. So it is kind of like an
exclusive lock. If I understand correctly, other people are allowed
to check out the file, but they can only get an unreserved checkout,
and they run the risk of not being able to merge.
Unreserved is more or less like CVS's optimistic locking system.
Coming from that background I would kind of prefer -unreserved to be
the default, and that's what I normally use. I guess optimistic
locking freaks out some people when they first hear the idea.
One thing that *really* bugs me about this system is that as far as I
can see there is no escape: if somebody has a file locked, then only
they or the administrator can unlock it. If you're in a different
timezone to all the administrators that is a real pain. I feel pretty
strongly that there ought to be a --force option that lets you go
ahead and break the lock, and deal with the consequences later. (You
can't even fudge the file permissions in your own view to make it
build, because CC hooks the filesystem level, but that's a whole other
rant.)
I guess it's fine if you can prohibit this in a hook script, and
probably ClearCase does allow that, but I would rather that it default
to trusting the programmer.
Anyhow, one thing that is quite interesting is that you're prompted at
checkout time for a message describing what you're going to do to the
file. This later becomes the default checkin message, though you can
edit it at checkin time. This message is visible to other people, so
they can see a description of what you're doing before you check it
in. You can also use it as a reminder of what files you have checked
out and what you're meant to be working on, which is useful on Monday
mornings. They're a kind of "work in progress" yellow sign.
Checkout comments are one of several ways of trying to avoid treading
on each others' toes. Locks are another; code ownership is another.
I think checkout comments might in some circumstances be superior to
locks, if only because they can convey more information than a single
locked/unlocked bit. A good message might tell you whether your
changes are likely to conflict, and whether you need to speak to the
other programer.
Of course, you could convey this information by other means, such as
email, and in some ways that is better. However, for a large tree, or
a lot of programmers, perhaps putting the note right next to the
relevant file makes it more likely that it will be seen. Presumably
you can write hooks for checkouts that send mail or whatever.
Checkouts in ClearCase apply to directories too, so you can't add a
subdirectory if the parent is not checked out. For example, you might
want to completely lock down a directory tree if you're about to try a
hairy merge operation and you don't want to restart because somebody
changed it under you.
I am not at all suggesting that Subversion needs to get these
features, or even that they would particularly fit the model, but
hopefully people might find it interesting.
Perhaps a nice system would be this: there are several levels of
possible locks on a file.
- gentle: gives a warning that the file is being edited by somebody,
but other people can commit anyhow
- firm: prevents new versions being committed, but can be overridden
with some kind of --force option
- strong: only the lock owner or an administrator can remove the lock
I do think that locks will be enormously more useful and less annoying
if accompanied by explanatory messages; oftentimes the message alone
may be enough.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 16:10:14 2002