Mark Phippard wrote:
>>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.
Sure, repairing or reinstalling TSVN would fix that. But before people
do that they come complaining on the mailing list. You see, the
apr_iconv libs aren't "vital" for the app. Users won't miss them until
they deal with files which have non-ASCII chars in their names.
> 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
I doubt that people would be happy if I told them:
To use TSVN you must first go to the website x, download and install y,
then install TSVN. We're talking about Windows users here: they want to
doubleclick on an installer and expect that everything works after that.
(and that's what I most miss on Linux: I can't even tell you how many
hours I've already spent searching, downloading and building required
libs for a simple app I needed. And once I thought I had all the libs
then those libs themselves needed yet another lib I had to download first.)
> 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.
As I mentioned before, you could also just copy the dll's over to the
other program folders and replace the ones there. But if you do that you
will _know_ what you do and if something breaks you will immediately
know that this could be the reason.
> 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?
I don't know. Maybe it would have worked, maybe not. Since I don't know
why those two different C-runtimes interferred and how they interferred
I just don't know if it will work that way. And I don't like to guess
when it comes to a program I release to the public.
> 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?
That would work for Subversion and TSVN. But what about the other
clients which don't use VS.NET at all?
>>- 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.
I don't think so. Back then, it too was an official release. And you
don't think that the subversion developers would have released that if
they knew it was broken? It was a mistake which could happen to anyone,
and it could happen again. It could also happen to TSVN - and if that
ever happens I don't want to be responsible for breaking other apps!
>>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.
I will sure use the dll's. And if Subversion makes it a requirement to
put those dlls in a common place I will do so. But as long as its up to
the clients where to put them I will put them in the TSVN folder. If you
then want to use some newer dll's from another client you can copy them
over manually, but then you're responsible if it doesn't work anymore.
Stefan
--
Build a man a fire - keep him warm for a day, set a man on fire - keep
him warm for the rest of his life.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 15 22:11:27 2004