SteveKing wrote:
> 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 famous "dll hell" is and always was the result of incorrect
packaging and not paying attention to details. There is no difference
between Unix and Windows in this respect.
> 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.
AFAIK that's true of .NET assemblies, not ordinary DLLs.
> Imagine Subversion 2.0 comes out and the dll's still have the same name.
They won't, by definition. They'll change from libsvn_foo-1.dll to
libsvn_foo-2.dll.
> 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?
You don't have to, see above.
> 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...
AFAIK _that_ particular problem was caused by TSVN not installing the C
runtime where every other app expects it.
> 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.
I do. It's very simple. Don't live in a world of your own. Coordinate
these things with the core project. I'm sure we can define an
installation scheme for the libraries and all clients that will make
them work together.
Really, this is ridiculous. If you're going to fork APR-iconv for TSVN
-- a crazy scheme if I ever saw one, it's one of the most stable parts
of APR -- you may as well fork SVN itself, for all the good it does us.
I proposed to introduce a well-defined interface to the (upcoming)
Subversion core installation for other clients. Our strict API
guarantees allow us to do this. You can either help with this effort in
such a way that it benefits TSVN as well, or you can go your own way.
It's your decision. But if you decide against helping with a common
infrastructure because of some "dll hell" FUD, well, that's tough,
you'll be duplicating work that others could be doing for you.
(Funny, I'd been considering getting "svn status -N" --
svn_client_status, in fact -- to work a bit better, so that TSVN could
have less performance trouble with the overlay icons. Now I wonder if I
should bother.)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 14 23:50:55 2004