"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. Adding a common caching mechanism is one
was to solve this issue. (Probably not the only way, and possibly not the
best way.)
> > 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.
> > 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.
> > 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.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 21:58:41 2007