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...
Yup.
-- 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