Mark Phippard wrote:
> I disagree with you. I think it would improve the Subversion/Tortoise
> packaging if it was more obvious how they co-exist. Having a set of
> shared Subversion DLL's is the best way to accomplish that. Then when
> these security and other fixes pop-up I can just update Subversion and
> that takes care of everything.
"takes care of everything" - that's what's not possible: the "everything".
> Now that Subversion has 1.0, the API compatability guarantees, along with
> including the major version number in the DLL name, should make DLL Hell
> very unlikely.
I wouldn't say "very unlikely", maybe unlikely, but still possible.
> I hope you will reconsider and try to work more closely with the
> Subversion team to get this right. I would also like to see Subversion
You won't believe it, but I'm trying to make TSVN work so that no other
Subversion client gets affected, that each client can live on its own
without interfering with others. But there are some issues which prevent
me from doing it right.
Example: the infamous APR_ICONV_PATH environement variable
scenario 1:
- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
- TSVN client gets installed, sets APR_ICONV_PATH to \TSVN\iconv
--> SVN client doesn't work anymore, because the iconv which comes with
TSVN uses the msvc71.dll which SVN doesn't have.
(and no, the msvc72.dll should _not_ be in the windows system dir
because even MS advises against that)
scenario 2:
- SVN client get installed, sets APR_ICONV_PATH to \SVN\iconv
- TSVN client gets installed, since APR_ICONV_PATH is already set
doesn't change it
- SVN client gets uninstalled
--> TSVN won't work anymore because the APR_ICONV_PATH points to a
non-existing directory
What I don't get is why do you want all clients to use the same dlls
shared in one place? What would you gain by doing that? Don't start
talking about saving disk space - those 5 MB's won't affect you.
But the problems which _can_ arise are serious and real. Sure, with some
luck we would never have such problems. But I've lived long enough
(maybe too long already) to know that luck is something that only others
have.
Just some examples of what already happened so far with dlls:
- When I first started with TSVN I used the precompiled berkeley db
libraries from the subversion website. I thought it worked very well -
and why shoudln't it, I used the very same libdb.dll as the command line
client. But then I got sometimes crashes in TSVN which I couldn't
explain. Somehow the memory heap got corrupted, and I didn't know why. I
spent a whole week until I found out that the berkeley db from the
subversion website was built with VC6 and used msvc60.dll while TSVN
used msvc70.dll. Once I built my own version of the berkeley db the
memory heap wasn't corrupted anymore and everything worked great.
So there weren't even two different versions of the berkeley dll, just
the same version built with different compilers. Talk about dll hell!
- ZoneAlarm (firewall program) installs its own version of the
ssleay.dll into the windows system folder. This is not a problem for the
command line client since windows always load the dlls which are in the
program folder first, but TSVN is a shell extension and gets loaded by
the windows explorer - and the explorer is in the windows folder. So
users who have ZoneAlarm and TSVN installed get an error message on each
login telling that an entry point in the ssleay.dll wasn't found. Not a
serious problem, but definitely _very_ annoying.
- Some time ago a subversion client was released which was broken on
windows. The apr_iconv library wasn't working. That time only the
subversion client was broken, but with a shared library _all_ already
installed and working clients would have been broken too.
- The apr_iconv *.so files don't have a version information built in (no
version resource), so installers can't check if they probably will
overwrite a newer version with an older one.
But it's not only TSVN and Subversion which would run into possible
problems. Even MS has problems with different dll versions. Just browse
the MS knowledge base to find out how many times a bugfix/securityfix or
servicepack (which should _only_ fix bugs and not change the API at all)
broke other apps (e.g. the LSASS fix made some win2k machines boot up,
but then use 100% CPU and render the PC unusable).
What I'm trying to say is that we use one shared library then a newer
client _could_ break older ones (not intentionally). And then there's no
way to make the older client work again, because by reinstalling the
older client it would see (hopefully) that the libs already installed
are newer and _not_ overwrite them, so that client stays broken.
But if every client uses its own libs then a newer client won't have
even the slightes chance to break other clients, so that's definitely
better (so I think). If you then still want the older client to use the
newer libs just copy the lib files manually. If it then still breaks you
will at least have a chance to make it work again by reinstalling it.
Maybe you now think that I'm just paranoid about clients breaking. And
maybe you're right. But I've seen apps break too many times already to
just _hope_ it will work - I want proof!
To sum it up: I'd rather have each client use its own libraries which
they are tested against. It's much less risky and doesn't cost much.
> and Tortoise get together on build instructions for Windows. The
> Subversion docs does it one way and the Tortoise docs do it another. The
> problem is that Tortoise needs the Subversion files in the proper places
> for it to find them, understandable. It is also understandable that when
I don't see the problem. Where's the difference in the build instructions?
Stefan
--
Light travels faster than sound. That's why some people appear bright
until you hear them speak.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 15 21:26:17 2004