>
> 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.
> 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).
> 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.
> 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.
> 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.
> 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...
> 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...
> 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...
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 21:13:41 2007