Thank you for the thoughtful reply, there is no question that this is a
difficult and complex problem in Windows and with a bad history. I do not
entirely disagree with your viewpoint, particularly where it comes to the
3rd party libraries that do not appear to put the same effort into
packaging and compatability that Subversion itself is trying to do.
> > 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.
I believe you!
> 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)
I agree and it also potentially ups the user requirements for the install.
> 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
OK, but is this scenario seems better than scenario 1 as it is less likely
to be a problem. Also, wouldn't the repair option on your MSI fix it?
This one seems the lesser of two evils.
> 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.
In the case of Subversion itself, because it reinforces the concept that
tools like TSVN and JavaHL and Subclipse are built on top of the
Subversion libraries. It is just more clear what is doing what if the
instructions make me install Subversion client before I install the
others. Also, when Subversion issues something like a security fix you do
not have to stop your development to build and create a TSVN version of
the same fix and I the user do not have to install in my case 3 updates
(svn, tsvn, subclipse) to get 1 security fix.
> 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!
That one stinks. Is it possible if you were just using SVN DLL's which
were doing all of the talking to the BDB DLL's that this might not happen?
If this were the one and only holdup perhaps SVN could agree to do their
official release builds with VS .NET instead of Visual Studio 6?
> - 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.
I had a similar problem with Subclipse. It was hard to figure out the
root, then simple to fix.
> - 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.
Is it reasonable to say that now that we are at 1.x stage these problems
will not happen again in official releases? The client was pre-release in
those days.
> 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.
When and if Subversion moves to a DLL model, I would like you to at least
take a look at what they have done and see if it is something you could
take advantage of.
> > 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?
>
Perhaps it is not a problem any longer. I seem to recall that the
relative locations of some of the folders were in different places. The
SVN instructions have SVN, HTTPD, OpenSSL, ZLIB all as peer folders at the
same level, I thought that you put one or more of these below the SVN
folder.
Thanks
Mark
---------------------------------------------------------------------
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:50:20 2004