On Tuesday 02 March 2004 01:02 pm, Brian Mathis wrote:
> GreyGeek wrote:
> >The 'error' is in using tarballs in the 21st century. It's like still
> >starting your car with a hand crank and spark adjust. It's been my
> >observation that compiling tarballs was very reliable two or three years
> > ago. I usually had an 80-90% success rate. Now, that rate is 10-20%
> > because so many apps are depending on distro specific versions of
> > libraries and when one tries to downgrade or upgrade to that specific
> > version cascading
> >dependencies and conflicts arise. At some point you throw up your hands
> >and say forget it.
> >
> >Just as an indication of how weird it is getting... I was unable to
> > install Subversion with MDK 9.2 specific rpms, but I was able to install
> > RedHat rpms on my MDK 9.2 box (I needed to overcome only 6 conflicts
> > which required a total of NINE RH rpms to resolve) and get Subversion
> > running. But, as Fedora, MDK, SUSE, etc., continues down their paths
> > the divergency between their libraries will make this cross-over less and
> > less likely to succeed.
> >
> >>FYI, on NetBSD, the steps to build subversion, and all its
> >>dependencies if you don't have them, from source, are:
> >
> >FYI, I don't run NetBSD and probably won't ever do so.
> >
> >GreyGeek
>
> Sorry, but tarballs are still very important and useful. You just need
> to know when to use packages and when to use tars.
>
> I usually use packages for all the base and peripheral stuff in the OS,
> but for the purpose that the server is actually for (web server,
> database, svn, etc...) I will compile that software from tars. Normally
> they need custom configuration anyway, and usually the OS packages are
> not up to date with the recent tar releases, in almost all software.
>
> I also was quite annoyed the first few times I tried to install svn - I
> even gave up a few times. I have much experience using tars and
> compiling, and I really had to work at it. Eventually, I figured it
> out, and since then some other people have posted some nice step-by-step
> instructions on how to do it on *nix. For things like Berkeley DB,
> there's no reason you need to upgrade the system version of it, you can
> install it in a private location.
>
> I do agree that the install process could be simpler (like maybe
> including the src to things like neon in the src tree, statically linked
> binaries), but as far as svn holding back the World Domination of Linux,
> that's just way off.
True, it was an exaggeration... but I marked my tome as a 'vent' ;-)
> svn is not a tool for end users.
What is your definition of an 'end user'? If a coder wanting to version
control his software isn't one then who is?
> As more and more people begin to use svn, they will figure out easier
> ways to do things including install, and hopefully contribute them.
> That's the wonder of open source!
True. SVN has great promise. And when installation gets as easy on a Linux
distro as it is on a Windows platform then SVN will find a home on a lot of
desktops and servers. What's the competition? BitKeeper and TLA? BitKeeper
has some annoying server 'problems' and TLA isn't cross platform. So, it's
either CVS or SVN. I am going to stay with SVN on my W2K workstation and
hope that the Linux side catches up soon.
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:42:15 2004