[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: Jim Blandy <jimb_at_red-bean.com>
Date: 2002-08-06 23:38:17 CEST

"Bill Tutt" <rassilon@lyra.org> writes:
> > Overall, the goal here must be to communicate something to the user,
> > not to try to force them to behave a certain way. But it seems to me
> > that some of the mechanisms described go beyond facilitating
> > communication, and try to force behavior --- which is both obnoxious
> > and ineffective. I could be misinterpreting the intent, but that's
> > the transgression I object to.
> Well, how else are you going to facilitate the needed communication at
> the appropriate time (whenever someone goes to edit one of these
> non-mergeable files) if you don't try to force behavior by making it
> read-only?

I don't object to making files read-only. I said it's the best we can
do in some cases. It's a reliable reminder mechanism, and it's easy
for the user to work around it in their local copy if they choose. It
doesn't force behavior, in the sense that I meant: you can just chmod
the file, and work on your local copy as normal.

Folks have described systems that won't even let you chmod +w a locked
file you want to modify anyway. That seems counterproductive. Once
the user's got the message, the system should get out of their way.

Folks have talked about locks that require an administrator's approval
to commit through. Again, that seems counterproductive. As long as
breaking the lock leaves a record, and each version of the file is
still available, there's no additional harm done. By the time they're
ready to commit, the user has already made modifications to a file
locked by someone else. When that file isn't mergeable, they've got a
problem. But you don't make that problem go away by not allowing them
to commit. And you do allow people to work around unresponsive or
thoughtless colleagues.

In these cases, it seems to me the VC system's job is to:
- make sure users are informed about the status of the files they're
  about to edit, and
- make sure that mistakes can be found and undone.

I don't want the VC system to be the policeman. Software is lousy at
that. The VC system should help people avoid committing crimes
accidentally, and it should provide a clear record that allows the
policeman to investigate crimes, and to set things right again.

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