On Mar 22, 2005, at 11:07 AM, Brad Kittenbrink wrote:
>
>
> Ben Collins-Sussman wrote:
>> By the way, before playing with locks, you might want to read:
>> http://svn.collab.net/repos/svn/trunk/notes/locking/locking-ui.txt
>> ...so you know what to expect.
>
> Just looked at this and I have some questions. We are using a tool
> (Maya - http://www.alias.com/eng/products-services/maya/) that
> unfortunately falls under the "Hijacking Scenario" and silently
> ignores the read-only attributes of files until it's too late. Many
> of my users are type 2 users (although I'm gradually converting them).
> What is the recommended way of preventing hijacking?
If I hijack happens, then the damage is already done, right? Two
people have edited a non-mergeable file, which means that at least one
of them has wasted time.
That said, I don't think there's *any* way to prevent hijacking,
certainly not when every user has a private working copy of the project
on local disk. The only foolproof method of prevention (AFAICT) is
what Clearcase does: make all working copies live on the server, as a
mounted network filesystem. And that's not something we can do. :-)
> With a hijacking editor is there any advantage of using svn locking?
Well, locking will still "work" in the sense of serializing access to
the resource, but it won't prevent people from accidentally wasting
their time. So my answer would be "no, probably not."
> Is there a way (or a way planned) to require a user to hold a lock
> token in their wc in order to read a file?
How would this work? How could any part of Subversion possibly prevent
some random editor from reading a file or changing the file's
permissions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 22 18:58:41 2005