kmradke@rockwellcollins.com wrote:
>>> 3. The lock information might be out of date as soon as it is
> retrieved
>>> (but version information won't?)
>> Right. Both lock and version information is out of date the minute you
>> retrieve it. That's the basic assumption in the Copy-Modify-Merge
>> model. Everything is outdated the minute you retrieve it, therefore
>> you need tools to help you resolve differences between your local
>> changes and the changes later retrieved from the server.
>
> Providing "File is locked by someuser. Status was last checked on 9:07am,
> Nov. 21, 2007 CST"
> information without having to contact the server would be useful
> information to my users
> and it explicitly informs them when the information was last gathered.
And the converse? If the lock didn't exist when that check was done but
was subsequently created? Even if you check in real-time, unless you
create your own lock you have no reason to believe that someone else
won't lock before you start your changes.
>>> 4. If a GUI client wants to offer the feature, each one should do it
> in
>>> their own way.
>> No. They should all do it the same way: give the user correct
>> information (ie the CURRENT status) by querying the server real time,
>> online, read ahead, whatever you want to call it.
>
> This just doesn't scale well. We have 1500 active users, all across the
> world
> accessing 400 repositories holding TBs of data in hundred of thousands
> of versions. One of our primary reasons for moving away from ClearCase is
> the reduced dependency on real-time connectivity to our servers.
I don't see how you can expect a cached view of an existing lock to mean
something (which it doesn't really mean since it can be unlocked without
anything else happening) without also expecting the cached concept that
a lock does not exist to mean something that will cause trouble.
Wouldn't you be better off setting 'needs-lock' on files where
concurrent changes can't easily be merged and always obtaining a lock
yourself when needed?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 22:17:59 2007