--Kjell H Andersen <email@example.com> wrote:
> Bruce Webber wrote:
>> --Kjell H Andersen <firstname.lastname@example.org> wrote:
>>> That's actually only half the truth.
>>> By setting svn:needs-lock, the files will be read only when you check
>>> them out. If you acquire a lock, the file will be read enabled. However,
>>> if a user decides to make the file writable by using chmod +w (or
>>> unchecking the Read only tick in Windows), there is nothing that
>>> him from editing the file and then committing it.
>> If someone has locked the file, no one else will be able to commit it.
>> Changing the read-only property of the file in the working copy does
>> not circumvent this.
> This is true, but if no one else has acquired a lock, there is nothing
> that prevents me from making the file writable and then committing it.
> The locking isn't strongly enforced by the system in a way that prevents
> me from editing the file unless I lock it. The problem arise when I start
> to edit the file without locking it, and then someone else locks the file
> before I commit.
I agree. Subversion's locking mechanism is driven from the client rather
than the server, which allows for the problem you describe.
>>> I would suggest some kind of clever hook script similar to the one that
>>> prevents tags from being edited.
>> Another possibility is to make changes in the auto-props section of
>> the Subversion configuration file on each PC. There you can specify
>> that files with certain extensions will have the needs-lock property
>> set whenever they are added to Subversion. The drawback here is that
>> it has to be done on each client.
> I have done that at my company, but still, there are some applications
> that don't care too much about a read only file property and let the user
> edit the file anyway. The svn:needs-lock is not a secure way of
> preventing bad things from happening unless the users are fairly well
A quick test showed us that FrontPage is one such application. Needless to
say, we don't use FrontPage!
I agree - the users need to be trained and need to follow the process to
avoid getting into trouble.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Dec 19 16:39:06 2005