Mark Phippard wrote:
>>Sure, repairing or reinstalling TSVN would fix that. But before people
>>do that they come complaining on the mailing list. You see, the
>>apr_iconv libs aren't "vital" for the app. Users won't miss them until
>>they deal with files which have non-ASCII chars in their names.
> The way I see it in scenario 1 something is definitely broken, in scenario
> 2 something is only broken in the less likely event that the Subversion
> client is uninstalled.
Maybe unlikely for you. You're forgetting those users who first try
Subversion with the official client, then go searching for a GUI client
(they're Windows users!) and if they find one they like the uninstall
what they don't need anymore.
> But you are trading off having to do this once, when many people will want
> both installed anyway, for having to update multiple clients every time a
> fix is released. Also, I think in the long run it is better for you if it
> is clear to your users where the core Subversion functionality is coming
Users don't usually care where a library comes from. They just want a
program that works - they don't care how or why.
Imagine Subversion wouldn't install all the libraries it uses but would
require the user to download and install them separately (openssl, neon,
zlib, berkeley db). For a Windows user that's just not acceptable (and
another reason for MS to shoot at open source projects). Ok, you say you
have to do that only once. But you're forgetting that once that's done,
users will have to monitor all project websites for new releases and
then read all the release notes to make sure the new releases are
compatible with each other. Users don't do that - Computer geeks do that.
> Perhaps if your installer found the Subversion DLL's in the path it would
> just skip installing another copy?
That would still mean TSVN would have to use the libs it is not tested
> Since Subversion adds itself to the PATH, and you do not, wouldn't you get
> the Subversion DLL's anyway?
Subversion _has_ to add itself to the path since it is a command line
client and could otherwise not be started from a working copy folder (at
least not without specifying the full path each time). TSVN doesn't (and
shouldn't) do that because it's a GUI and isn't started like the command
And no, TSVN wouldn't (doesn't) use those dlls: a program always loads a
that dll which resides in the same directory as the application itself -
only if it doesn't find it there Windows then looks in other folders
(including those in PATH) for that dll - the order of those locations is
different for Win98 and NT based OSes. See the MSDN for the exact
God is Real, unless declared Integer.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jun 15 22:38:04 2004