[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems building trunk on Win32

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-06-15 22:18:25 CEST

SteveKing <steveking@gmx.ch> wrote on 06/15/2004 04:09:54 PM:

> >>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.

The way I see it in scenario 1 something is definitely broken, in scenario
2 something is only broken in the less likely event that the Subversion
client is uninstalled.

> > 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.)

But you are trading off having to do this once, when many people will want
both installed anyway, for having to update multiple clients every time a
fix is released. Also, I think in the long run it is better for you if it
is clear to your users where the core Subversion functionality is coming
from.

Perhaps if your installer found the Subversion DLL's in the path it would
just skip installing another copy?

> 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.

Since Subversion adds itself to the PATH, and you do not, wouldn't you get
the Subversion DLL's anyway?

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 22:19:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.