JS.staff wrote:
> I don't have any gripes really (being new), but have you thought
> about posting a list of issues *you* think are a problem with SVN, so
> that the rest of the TSVN users group can hassle the SVN people
> about??
As it's Subversion policy (and TSVN's too): everything has to be
discussed first on the mailing list. Issues are only filed if there's a
consensus about a problem/bug/enhancement/...
So I do report the problems on the Subversion mailing list, and if
there's a consensus then I file an issue. There are some issues in the
subversion issue tracker which I started.
The problem is: even if there are issues filed, that doesn't mean that
they get fixed/done.
Sure, you could say that if it bothers me that much I could write a
patch to solve the issue. Been there, done that.
Example? Here you go:
Since TSVN links against the Subversion library twice (one
TortoiseProc.exe and one is TortoiseSVN.dll) it would save a lot of disk
space if Subversion would compile in a dll and not just link statically.
So I suggested that on the mailing list (about 1.5 years ago). Consensus
was there, but no one there seemed to have the time (or the motivation)
to do it. So I wrote a patch for it. I did it the same way the apr
library does it - I thought since Subversion uses apr that this would be
ok. Wrong! My patch got rejected. They'd rather have some script which
would automatically generate a def file for the dll. I told them that I
don't know perl or python so I couldn't write that script.
So, instead of using a patch which worked (tested myself with TSVN),
they rather wait for a script which most likely will never be done. At
least it hasn't been done yet.
I did some other patches which got rejected too. So I stopped working on
the Subversion library completely. I'd rather work on TSVN where my work
is put to good use than to work on Subversion for nothing.
So if I think something should be done in Subversion, I write a mail to
the dev list there, try to explain why I need that fixed/done. But
nothing more. If they don't react or simply reject the idea, I stop
discussing - I've got better things to do than wasting my time. If then
later the problem I mentioned comes up and bothers lots of TSVN users, I
have to tell them to complain on the Subversion mailing list, hoping
that many people complaining will convince them to do something about it.
And in the case of the apr-iconv library, well, if they don't do
something, I did. apr-iconv is now patched for TSVN. I haven't told them
that I patched it - maybe I should because I know that will get them
angry ;)
> My only issue is with the .svn / _svn thing (yeah, I know, it's all
> been discussed before my time! LOL). But I'm gonna say my piece
> anyway :)
>
> It's not your problem Stefan. In my opinion the standard folder name
> should be '_svn' in Windows on *all* clients, and '.svn' on Unix.
>
> There's a good reason for having a leading period on a Unix file
> system, it means something special. But that isn't the case on
> Windows. You could call it 'SecretHiddenSubversionFolder' for all
> Windows would care!
The problem is: Windows can handle the .svn directories _very_ well.
Only the VS.NET web projects have a problem with them. And who's to say
that if you change the name to _svn that no other app will have a
problem with those?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Aug 14 12:29:37 2004