> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: Wednesday, November 21, 2007 4:06 PM
> To: kmradke@rockwellcollins.com
> Cc: Bicking, David (HHoldings, IT); Harvey, Edward; Les
> Mikesell; users@subversion.tigris.org
> Subject: Re: Communication of LOCKS and CHANGES
>
> On Nov 21, 2007 9:57 PM, <kmradke@rockwellcollins.com> wrote:
> > "Erik Huelsmann" <ehuels@gmail.com> wrote on 11/21/2007 02:13:08 PM:
>
> Right. But where it went wrong is that they started caching
> information which we have thought long and hard about caching
> but decided against. It wasn't something we left out after
> tossing a coin...
No such caching exists as far as I know. The issue I presented is what
would happen if such projects did implement their own caching, which is
probably why they do not.
> > Like it or not, a version control system is inherently
> providing some
> > type of communication method. (I.E. the simple log command is the
> > same as phoning another user and asking them what they are working
> > on.) No reason to force users to resort to other mechanisms if the
> > information is available.
>
> It's available. But the only reliable source is the
> server.... Which is why we're not caching it...
Um. Yeah.
>
> > > > 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.
>
> As pointed out by others, the absense of that information could (and
> does) suggest the file isn't locked. That's the confusing part.
No more confusing that the current situation, is it? The fact that a
solution doesn't solve every problem does not invalidate it.
>
> > > > 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 think you misinterpreted me here. I just meant that one
> should query for the active list of locks. Not the entire
> working copy located on a server.
Up to 1500 active users doing an active query for lock information on
the entirety of a large project would be rather detrimental to network
and server performance, don't you think? OTOH, are you saying that the
internal representation of the locks is kept in a separate tree, and
only has as much data to scan as there are locks?
> Bye,
>
>
> Erik.
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 17:44:49 2007