> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: Wednesday, November 21, 2007 3:13 PM
> >
> > 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.
Ah. I misunderstood.
>
> > 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).
Extra coding and spam emails (immediately out of date) are okay. An
unobtrusive icon in an IDE is not. Understood.
>
> > 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.
Thus, arguing that you won't cache lock information because it is
immediately out of date does not make sense.
>
> > 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.
See my just posted response to another message saying the same thing.
>
> > 5. As soon as lock communication is available, developers will stop
> > trusting Subversion and each other.
>
> I have no idea what you're trying to say here. What I say is
> that as soon as a feature isn't presenting information which
> is correct (most of the time) it's not much of a feature and
> users will ignore it.
> Nothing about trust, simple logic combined with experience.
Semantics. You said they will ignore the data. I translated that into
distrust of the data, as I can't see another reason they'd ignore it.
>
> > 6. It is perfectly normal for a developer to simply decide
> the lock-er
> > is clueless, break the lock, and continue doing their own thing.
>
> That's for you and your team to decide. It may be and it may not be...
Got it. I would not want to be on a team that ignored locks, though.
> > I totally disagree with all those reasons, but there's
> nothing I can
> > do about it. Since nobody else is jumping in to my support, I can
> > only conclude that I am the only one who finds this
> peculiar. At this
> > point, all I can do is lay out these points for posterity
> and let it
> > drop, so that is what I am doing.
>
> That's because you're expecting things which can't be done
> within the philosophy of the product. What you want is
> perfectly legal in a different set of circumstances: if the
> client were to require a realtime connection to the server
> anyway, it wouldn't be too hard to provide the user with the
> correct feedback in the first place. That's where ClearCase
> comes in: they have all working copies on the server and the
> server can tell each client everything about all other
> working copies in the system. Subversion doesn't work that way...
I still disagree that Subversion must work that way for the information
to be useful. C'est la vie. It is clearly a philosophical issue,
though, and thus one not worth fighting.
>
> > On the bright side, I now have a good reason to learn how
> to make my
> > own additions to Subversion. My expertise is Java and C#,
> but I can
> > learn gnu c. I just need to carve out the time somehow.
> Of course,
> > it'll never be merged into the project, but at least I can have the
> > satisfaction of doing it.
>
> It would be too bad if you were to do that. There are APIs to
> get the required information from the server... I can't stop
> you however from doing it. If you will ever get to a state
> where you'll be releasing it, please be very careful about
> naming it, because it might not be forward compatible with
> Subversion clients...
It's not getting the information I'm considering, it's storing the
information. The only change to getting the information I might
consider is adding an option to get both sets at once.
>
>
> 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:36:21 2007