> There's a dilemma here, known as "Windows DLL hell". Since we have no
> control over installations, we can't prevent somebody from
> _downgrading_ the installed DLLs. If the DLL names in svn-1.x are the
> same as in svn-1.x+1, the newer stuff will break.
No control over installations? I'm sure some overwhelming percentage of
Windows users use the official Subversion MSI packages.
You can't prevent someone overwriting the dlls, but I don't think you
need to worry about that scenario. If the official Sibversion installer
installs C:\Program files\Subversion\bin\libsvn-1.dll then the end
users heads be on it if they attempt to overwrite that with an earlier
OR later version without using the corresponding installer.
If you were to install the DLLs in c:\windows\system32 then DLL hell
would be a problem. So don't do that!
I don't even think you need to include the major version number in the
file name. Just looking in my C:\program files\Subversion\bin\
directory, there is:
intl.dll, intl3_svn.dll, libapr.dll, libapriconv.dll,
libaprutil.dll ... svn.exe, svnadmin.exe, svndumpfilter.exe ...
In fact the only files in here with any kind of version numbers in the
filename are the BDB ones (libdb42.dll, libdb43.dll)
I don't have any DLL hell problems with libapr.dll. And why isn't that
"svn1.exe" or "svn-1.2.1.exe" then? I have a couple of scripts that
parse svn.exe output, they could equally break if I downgraded say to
svn 1.1
I can run two versions of Subversion by installing one in c:\program
files\svn1.1 and another in c:\program files\svn1.2\ or the like
The issue of MSVC6 vs VS.NET (vs Borland C++ builder vs...) is possibly
a good one - although I would have expected that could be solved by
defining the calling conventions properly. That may be more work thatn
any wants to do though.
Perhaps the biggest problem is that with open-source products like this,
people can create their own custom builds and break something that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 01:49:05 2005