Eric J. Smith wrote:
> I've only been part of this list for a short while now, but it really seems
> like the Subversion people would give the person doing the majority of
> development on what, I'm assuming, is the most popular Subversion client by
> far a little more respect than this.
Respect? No, don't think so.
They haven't even fixed a bug which crashes the "check for updates"
dialog even though I've reported it four times over the last six months,
and the fix would be to add a simple NULL-pointer check! They rather
have TortoiseSVN crashing than fix it - they said they wanted to know
exactly _why_ this crash happens, not _where_.
:(
> If you wanted to store the issue tracking properties with a revision given
> the current limitations of Subversion, I'm guessing you would have to make
> an extra call to add the properties after the commit was successful? Also,
Yes. And that would make a commit non-atomic. That's why I didn't wanted
to do that.
> I'm guessing what you are talking about when you say custom server config
> files is that you would tell Subversion to always send back certain
> properties (like issue tracking properties) like it does with the log
> message now? If this is the case, I wonder if they could simply be talked
Not exactly. What I was thinking of is a file which would be stored in
the repository but not in the visible tree. And that file would be
updated with every update, no matter which folder/file you update in the
working copy. Also, that file would be stored in the Subversion user
folder (like the auth data is stored now) so that it doesn't matter
which folder someone checks out - the file will always be there.
Then, to read those server-side configs, no repo access would be necessary.
> into providing some streamlined way in the API of requesting specific
> properties along with the other revision metadata?
You already _can_ read revision properties through some API calls. But
that would require an additional connect to the repository server for
each property you want to read.
> Also, I'm wondering if these extra calls would really be all that bad?
Yes. They would be.
> Anytime someone includes an issue number with a commit you would make an
> extra call to apply the properties after commit. And you would only need to
> make an extra call to get the issue tracking properties for the show log
> window and you could just get the information as it is needed (when a
> specific revision is selected). Also, you could retrieve this information
> asynchronously so the client wouldn't have to be slowed down.
Since the issue number box should only be shown if the properties are
actually set, this would mean a connection to the repo server before the
commit dialog is even shown. And that's very bad. Many people use the
commit dialog to just check which files have changed.
> I know that you have this implemented and working already, I just hate to
> see the data stored in the log message and parsed out if it doesn't have to
> be and if storing the data as properties is an option, now is the time to
> change it rather than waiting until after the official TSVN 1.1 release.
You can't get anything new into 1.1 anymore. That ship has sailed. Only
bugfixes can get in there now, anything else is put on hold for 1.2.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Sep 11 20:15:16 2004