This is a general comment on the TSVN/Subversion dll debate.
I would like to point out that the Microsoft solution to dll hell in
.NET is that every assembly which uses another assembly has it's own
copy of the dll's. I.e., if TSVN and Subversion programs were .NET
programs (there's a thought!) TSVN would use the Subversion assembly and
Visual Studio .NET would copy the Subversion dll's into the TSVN
assembly. Installing TSVN would mean copying all the required assembly
dll's into the TSVN assembly directory, including the Subversion ones.
Yes, there is a global assembly cache, but it isn't recommended that you
So even MS now believe the only safe way to do this is for each
application to have it's own copy of a dll which means that it cannot be
broken by another install.
So, I sort of side with Steve King because:
- Every windows application install should be complete in and of
itself. If I install TSVN I cannot be required to have installed
- TSVN could (and probably should) use the dll's from a Subversion
release, but it has to have it's own copy which it is known works properly.
- The 'common files' thing which some installers use are there for
companies who have a large product range which people buy in bits, so if
one buys product 1 it installs the common bits, then buy product 2 and
they are already there. That company will have built and tested its
products against that common code so it works. If there is a new
version of the common bits the company can make you upgrade all your
applications. I am not convinced that TSVN/Subversion can or even needs
to do all this.
I think that if you wanted common dll's you would have to have common
releases, i.e., there would have to be an install for Windows which
included the Subversion command line and TSVN clients, that way you know
what you are getting. Is it worth it? Probably not.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 16 09:36:28 2004