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:
>
> [...]
>
> Can't believe I'm providing fuel for the fire, but in the spirit of open
> source,
> I'll add in my perspective...
>
> > > Horrible, isn't it? You apparently would rather let each product team
> > > come up with their own cache format for their own plugin, and woe be
> it
> > > to the poor developer who uses two different tools at once (like us,
> > > Ankh and Tortoise). As soon as I update in Tortoise, the information
> is
> > > there, but Ankh is blissfully unaware, and the developr very quickly
> > > learns not to trust the information.
> > >
> > >
> > > Yeah. Clearly I'm not convincing anybody. I see the arguments
> against
> > > this feature come down to these points (combining Les' and Erik's
> > > arguments):
> > >
> > > 1. You shouldn't work "that" way, and if you do, Subversion should not
> > > help you stop.
> >
> > Wrong conclusion. The point I'm making is: if you want to work that
> > way, you're using the wrong tool. Buy ClearCase.
>
> This is a bit drastic. If people didn't try and use tools in new ways,
> they
> would tend not to grow.
>
> Apparently 2 GUIs (both TortoiseSVN and Ankh) have felt it was useful
> to provide "cached" lock information to their users. Since there isn't a
> common
> API to store this information, any user who uses both tools may see
> conflicting
> information. This is bad.
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...
> Adding a common caching mechanism is one
> was to solve this issue. (Probably not the only way, and possibly not the
> best way.)
But introduce new ones. We don't want part in (a) caching [because we
don't believe in it as a sound solution to the problem] (b) resolving
the problems resorting from caching.
> > > 2. Information about major code efforts should be communicated by any
> > > means EXCEPT Subversion.
> >
> > Also wrong conclusion: if you want to notify people, do so through all
> > means available (use post-lock hooks to send mails, RSS, etc) but
> > don't DEPEND on Subversion alone. Communicate with your colleagues.
> > Subversion is a Version Control System, not your phone and interface
> > to the people in the booth next to you (or on the other side of the
> > world).
>
> 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...
> > > 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.
> > > 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.
Bye,
Erik.
---------------------------------------------------------------------
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:07:43 2007