> 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.
Sure, to break break something someone has to make a mistake. But you're
making it too easy by just saying that it is the result of incorrect
packaging. Much too often programs broke because one dll changed only
slightly (a bugfix) and was tested against one or two programs, but the
third program broke because of this bugfix. I've seen that many times.
> > 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.
No. Normal dlls can have that too (on XP). The commctrl.dll is one famous
example. You have to add a manifest to your programs resources to make it
use the newer version which has uses the XP-look on the controls - otherwise
the old version of that dll is used (which has the same name).
> > 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.
Ok, so at least that won't be a problem.
> > 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.
True. But TSVN installs itself the recommended way! If other apps expect
TSVN to install the C runtime in the windows system folder then that's not
TSVN's fault. Even MS recommends to _not_ install those files there but in
the program directory where the program itself gets installed - and that's
what TSVN does.
So you can see: even though we already try to follow all rules of deploying
a program there's a problem because some programs/libs expect otherwise.
> > 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.
Can you guarantee that really _all_ clients will follow the rules? I can't.
> 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 have no intention to fork SVN. But I have to admit that I sometimes was
close to doing that (remember how long it took until the .svn folders got
hidden on windows?).
And no, I don't just fork other projects. First I try to convince the devs
there to include another function or change the API slightly so that it will
for me too. But if that doesn't happen then what other option do I have?
BTW: I mentioned the problems which will arise by apr-iconv using the
APR_ICONV_PATH env variable more than a year ago. Nobody believed me,
nothing was done. Now we have a problem. So tell me, what should I do?
Waiting another year and hope in a change in apr-iconv so it doesn't use
that env variable anymore? I don't have that much time...
> 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.
Even your strict API rules can guarantee that a client installs the library
correctly. May I remind you that even the subversion client once installed a
_broken_ iconv library?
> 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.
This is no FUD. This is real.
> (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.)
Don't worry about that. There are other bugs (e.g. when committing deleted
nested folders non-recursively) which affect TSVN much more.
Stefan
--
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 15 07:46:20 2004