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

Re: Locking on svn.collab.net (was svn.collab.net Subversion upgraded to 1.2.0-rc1)

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2005-04-12 19:11:36 CEST

--On Tuesday, April 12, 2005 11:18 AM -0500 Ben Collins-Sussman
<sussman@collab.net> wrote:

> I gave a justification in my mail: so we can experiment with our own dog
> food. That's a tangible benefit. I then proceeded to explain why
> there's no risk to leaving this door open.

Why do we even need to open the door in the first place?

> Yet when I read your mail, it looks much the same as cmpilato's: I see
> some sort of hatred of locks, or some perceived danger/annoyance, with
> no explanation. Can we have a rational debate, other than just blind
> voting?

As I said in my previous email, I'm saying that I don't think locks make
sense for this type of project. I do believe that locks have their place
in certain groups. Yet, Subversion itself just doesn't seem to me to fit
that criteria.

I worry that the introduction of locks would make it such that committers
would obtain locks on a file and then others would be hesitate to make
changes to that file because John has a lock on a file and he's being slow
on committing his changes. I think that's really bad behavior for
open-source projects: no committer should ever block anyone else from
making changes. Either the change is committed or it isn't. And, if it's
a long-term change, then you need to branch off and handle the merges. --
justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 19:14:19 2005

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.