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

Re: Locking consensus(es) so far

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-18 23:50:48 CEST

Ben Collins-Sussman wrote:

> On Oct 18, 2004, at 7:17 AM, Branko Čibej wrote:
>> You solve the non-techie problem simply by requiring locks on all
>> files in the repository by default, which means that a hijack can't
>> happen because the potential perpetrator won't be able to commit an
>> unlocked file (without breaking the lock, which you don't let
>> non-techies do anyway).
> Branko,
> I've already capitulated to the majority, on this topic. But I think
> you have a misconception of what "hijacked file" means, as described
> in the ui document. It doesn't mean, "commit an unlocked file". It
> means, "somebody's tool accidentally ignored the read-only flag,
> allowed someone to make edits, and now they have to deal with merging
> before getting a proper lock to commit."

Hmm, right, I was assuming something else... but in this case, a hijack
is exactly equivalent to any other kond of conflict, isn't it? "I can't
commit my changes because (I can't obtain a lock because) somebody else
beat me to the commit".

> There's only one SCM system in the universe that can utterly prevent a
> hijack: Clearcase dynamic views.

And not even that...

> No tool can circumvent the read-only bit on a dynamic view. :-)
> This is discussed in the ui doc as well.
> Just trying to make sure we've all got the same definitions here...


-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 23:50:57 2004

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.