Re: Problems building trunk on Win32

Jostein Chr. Andersen wrote:

> On Monday 14 June 2004 20.16, Branko Čibej wrote:
> ...
>
>>What I'm hoping for is that all Subversion clients start using the
>>same DLLs. Once that happens, you could theoretically fix a "bug" in,
>>say TortoiseSVN, by upgrading the core Subversion package (libraries +
>>command-line client, or just the libraries). If we get the packaging
>>right -- and get other projects to cooperate -- it would make using
>>Subversion much easier, IMHO.
>
>
> +1 on this one.
>
> We could then place all the common DLLs in NT's
> "%CommonProgramFiles%\Subversion" (and correspondig folder for 9x).

I don't like that idea at all. This is an invitation for problems and
crashs. Ever heard of the "dll hell"? That's exactly what will happen.
If a program uses (has to use) dlls installed by another app, maybe even
another version of those dlls than the program was written and tested
against it _will_ cause problems.
The %CommonProgramFiles% location is intended for software vendors who
ship whole suites which use all the same libs (e.g. adobe, macromedia,
ms, ...) but which all programs are tested against those libs.
MS even has introduced a mechanism in XP (and will be improved in
Longhorn) which allows to have several dlls with the same name but with
different versions to reside inside the same folder. Only that way it
can be assured that a program only uses those dlls it really knows.
Imagine Subversion 2.0 comes out and the dll's still have the same name.
Now you still have a client which needs the 1.0 dlls, but they're
overwritten by a newer client which installed the 2.0 version. Can you
_guarantee_ that the older client still works?
I also like to remind you of the problems we already have with the iconv
library: due to the APR_ICONV_PATH env variable all clients already use
(have to use) the same lib, even if it was installed by another client.
And you followed the thread on the TSVN mailing list about that too...

So for me this won't be an option and TSVN will never be part of that.
I'd rather work on real bugs in my program than having to deal with
issues arising from incompatible dlls. I will also patch the iconv lib
for the next release of TSVN so that it won't use the APR_ICONV_PATH
variable anymore - I don't see any other way to get rid of the reported
problems.

Stefan

--
"The best argument against democracy is a five-minute conversation with 
the average voter." - Winston Churchill
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org