"Erik Huelsmann" <email@example.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
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
> > 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
> > 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
> > 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,
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
API to store this information, any user who uses both tools may see
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
> > 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
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
> > 3. The lock information might be out of date as soon as it is
> > (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
> > 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
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 21 21:58:41 2007