--Simon Large <firstname.lastname@example.org> wrote:
> Edward Harvey wrote:
>> Can anyone tell me if this is possible?
>> I would like to administratively set something, such that... If Joe
>> locks a file, the file will automatically get "needs-lock" too. And
>> when Joe releases the lock, the "needs-lock" is automatically removed.
>> Consequently, as long as Joe has the file locked, that file in Lisa's
>> working copy will be read-only and have an icon indicating needs-lock.
>> (Assuming Lisa does an update.) And once Joe releases the lock, Lisa's
>> file will go back to "normal" with a green checkmark. (again, assuming
>> she does an update.)
> No it's not possible to do that automatically. svn:needs-lock is a file
> property, and to change that in the repository you would need to commit
> the file before locking to add the property, and commit again after
> unlocking to remove it.
> I guess in the way you want to use it, you can use locking without the
> svn:needs-lock property. If Joe takes out a lock, Lisa can no longer
> commit any changes - she must wait until Joe finishes his big change,
> then update (merging all his changes) and then she can commit her
> For non-mergeable files (mostly binaries) you should have svn:needs-lock
> set permanently, because no change is mergeable, however trivial.
What you could do is this: A client on the Lisa's PC could query the SVN
repository and check to see if files in her working copy are locked. If any
are, the client would make those files read-only. Then if Lisa is using an
editor that respects the read-only file attribute and displays that status,
when Lisa tries to edit the file she will know the file is locked by
someone. This is of course based on how often the client queries the SVN
I do think, though, that if you are going to use file locking it would be
easier to set the needs-lock property on the PCs, and have people lock the
file before editing it. True, it is one extra step, but it's not that hard
to do (in Tortoise, right click on the file and select Get Lock). If it
avoids problems this extra step is worth it (assuming they are developing a
product that has value.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Apr 27 16:59:44 2006