Edward Harvey wrote:
> Ok, I've heard the least objection to this idea, so let me run it by one
> more time --
>
> I'll talk to the subversion group, and hopefully get subversion to cache
> (in the entries file) the most recently known remote lock status.
>
> Based on this information, tortoisesvn can treat a remote lock as an
> implied needs-lock, meaning tortoisesvn can display a gray icon, and
> make the file read-only.
>
> Users must accept that the information displayed is only as current as
> the most recent update.
>
>
>
>> -----Original Message-----
>> From: Edward Harvey [mailto:eharvey@chilsemi.com]
>> Sent: Friday, April 28, 2006 6:10 PM
>> To: users@tortoisesvn.tigris.org
>> Subject: Ok, how about this -- (locks & lock communication)
>>
>> At present, if a file has the needs-lock property,
>> tortoisesvn will make the file read-only and mark it with a gray icon.
>>
>> Would it be ok to do the same thing, if the file is locked by
>> some other user?
>>
>> Tortoisesvn will not remove the gray icon, or make the file
>> writable, until you do an update, and either the needs-lock
>> property, or the remote lock have been removed.
>>
>>
This "topic" has been spread across multiple subject titles, with the
consequence that it has become somewhat difficult to piece together. And
having been "on-the-road" like Stefan means the emails are now spread
between lap and desktop machines, further complicating the process. Most
topics have now been done to death so I'm just going add a little bit
of life's experience to the mix when it comes to locking shared files.
I worked in an environment where shared access was controlled by a write
locking RCS which meant only one person at a time could work on (change
then commit) a file. We were all contributing mainly different
information but the process became serialized by the write locking and
consequently rendered very slow. Perpetuating needs-lock on files after
they have been write locked once when they don't need normally locking
is very bad because thereafter access unnecessarily becomes a serial not
a parallel access process.
Despite the above, the easier it is to inquire of the repo which files
are locked by whom better. (So you can jump on them before they go flying).
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Sun Apr 30 13:02:04 2006