On Tuesday 02 March 2004 09:51 am, John Peacock wrote:
> GreyGeek wrote:
> > The second experience was on my MDK 9.2.1 box at home.
> > Download source.
> > ./configure gives an error which cannot be resolved without rewriting
> > configure.in. Not going that route.
>
> To be honest, this is not a very helpful report, since you don't say what
> the error was. I have always been very happy with the speed by which I can
> build from source (with various distros). If there is something that you
> are seeing with ./configure, tell us so we can fix it.
>
> And to your larger gripe about the relative difficulty with installing on
> Win32 vs *nix, you have to understand a few things:
>
> 1) Subversion is built using very close to bleeding edge code; this will
> mean that most distro's will have older packages which will get in the way;
When did a 1.0 release start representing the 'bleeding edge'?
>
> 2) Subversion 1.0.0 is just over a week old; the distro repositories are
> either still serving up 0.37.0 (or GASP! older);
The MDK rpms were for the 1.0 release. So were the RH rpms.
>
> 3) Subversion relies heavily on a very new version of Apache (2.0.48) and
> recommends an even newer version of BerkeleyDB (4.2.x); since these
> programs are highly integrated parts of most commercial Linux distro's, it
> will take them a while to catch up;
I had no problems installing both of those apps.
>
> 4) Lastly, the Win32 distribution of Subversion is free to install all of
> it's own dependencies, since none of them are already resident on the
> system; it is a much more relaxed installation because everything is able
> to be installed without any fear of overwriting existing packages.
That's EXACTLY what Subversion should do, and other apps as well. It's called
a 'static binary' BECAUSE all the necessary libraries are included. HD space
is cheap and so is memory. The time I wasted trying to install Subversion
was worth more than any savings in HD space or Memory that might have been
saved by attempting to use existing libraries. Besides, it makes no sense to
ASSUME that specific versions of a library will be present on the target
machine when that library could be compiled into the app with little effort.
>
> It is out of the Subversion developers control how slow or fast any given
> third party packager gets a Subversion 1.0.0 RPM released. It is, in my
> experience certainly, far easier for the competent sysadmin to compile the
> few dependencies manually and install them in parallel with the distro's
> versions. All you _need_ is:
>
> A) Neon
> B) BerkeleyDB (use 4.2.x or 4.0.x, but stay away from 4.1.x)
> C) Apache 2.0.48 (and associated apr/apr-util)
> D) Subversion itself
Not quite:
Ignoring the Apache and BerkeleyDB requirements, which were no problem and
required regardless of the distro used,
an unsuccessful MDK installation required:
libdb4.0-4.0.14-6mdk.i586.rpm
libopenssl0.9.7-0.9.7b-4mdk.i586.rpm
libsvncpp0-0.5.0-1mdk.i586.rpm
subversion-1.0.0-1mdk.i586.rpm
subversion-client-tools-1.0.0-1mdk.i586.rpm
subversion-doc-1.0.0-1mdk.i586.rpm
subversion-python-0.29.0-2mdk.i586.rpm
subversion-repos-1.0.0-1mdk.i586.rpm
subversion-repo-tools-1.0.0-1mdk.i586.rpm
But installing using RH rpms required:
apr-0.9.5-0.2.i386.rpm
apr-util-0.9.5-0.1.i386.rpm
krb5-libs-1.2.7-10.i386.rpm
neon-0.24.4-1.i386.rpm
openssl-0.9.7a-20.i386.rpm
rapidsvn-0.5.0-7013.i386.rpm
subversion-1.0.0-1.rh90.i386.rpm
subversion-python-1.0.0-1.rh90.i386.rpm
I was unwilling to continue down the cascading dependencies and conflicts
during the MDK install, and 6 conflicts needed to be resolved in the RH rpm
install.
Neither had a GUI client that worked.
>
> I also don't see what your specific difficulty is at work; you say:
>
> 1) You are happy with the Win32 install;
Wrong. I am not happy with WinXX for all the known reasons. That SVN and
TortoiseSVN install on it so easily doesn't compensate for its many other
problems. If I had my way at work we would have switched to Linux last year
for all new application developments and gradually phase out existing
applications as their usefullness expired or we could replace them.
> 2) You have a completely Win32 shop;
True, but I am doing everything I can to change that, which is why I was
disappointed to find SVN such a hard install.
> 3) You don't want to teach them Unix.
Wrong, they don't want to learn and frankly, how successful do you think I'd
be if I showed them what I had to go through to get svn working on my box,
and only on the CLI at that?
First, having no Linux experience (that includes the IT dept and the sysadmin)
they'd experience shell shock, then they'd start laughing. It took me three
years of enduring ridicule to get a Linux box in the door. I don't want to
spoil that effort with this nonsense. Our shop is Windows on the
workstation, but it is Novell on the servers. SUSE 9.0 looked good to them
and I don't want to spoil it for them.
>
> My suggestion to you is simple: install the Win32 tools on the desktops
> and (if you want) install a Linux server for them to hit. QED
Remember, the idea is to migrate away from Windows. For example, I have
shown that Boa_constructor allows us to write apps whose scripts run equally
well on either platform, without modification, against our Oracle back end.
On both platforms the installation of Python2.3.2 and Boa_constructor
(pxPython, wxWindows and all of its other requirements) is easily down with a
few clicks. Migration is a snap.
For version control: CVS has too difficult to use in several important areas.
That is, after all, why you started the SVN project, is it not?
On Windows I was using CVSNT, TortoiseCVS and WInCVS, all easy installs and
easy to run, at least as easy as CVS allows (switching branches is no joy),
and on Linux it's CVS and Cervisia. I have switched my W2K box to SVN with
TortoiseSVN and I will stay with it because SVN is so good. My hope is that
SVN on Linux will rise to the level of usefullness ASAP, and my colleagues
will find it as enjoyable on Linux as they will on Windows.
QED.
GreyGeek
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 2 20:15:07 2004