This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Details for svn test repository
On 2005-02-11, at 00:29, Mark Mitchell wrote:
I think all we should be doing is making sure that the new system is
at least as reliable as CVS, easy enough to use, faster for key
operations, and provides good infrastructure for getting things like
file renaming handled correctly going forward.
OK right until now I was just using subversion on Linux for some toy
projects.
At least some moron at some distro vendor already did package it for me.
Now I have tried it out on MacOSX, which is nowadays my main platform
for anything
not embedded.
Wanted to use svn on it. First I went the supposedly easy binary way.
Well the http site itself brags something about fink distribution for
MacOSX. No way!
I'm not going to replace my fine system utility set with something that
isn't technically
necessary... Thanks. I happen to have no big deal problem with MacOSX
as it is...
Alternatively they pointed me to some package at some ominous internet
service
provider which seemed like a native Mac OS X package. A quick check for
the readme
turned my away in pure disgust - it was "client only" and creeping some
Java stuff in.
Java - I don't want it near any of my basic tools. Sorry I'm just too
lazy to go out
to by another gig of RAM. SVN itself was shattered in a bunch of
dynamic libraries. A
single one for development I could understand but apparently they think
that since it's
easy to create them you have to use them. No thanks! Hell is it a that
bad idea to make
applications self containing? Disgusting... (but typical nowadays).
Thus I went the "do it yourself" way. I have an /opt hierarchy on my
Mac OS X boxes
which I maintain by RPM, just to keep the stuff away from native
directories and to
have the packages moderately compatible in setup between the different
OS-es I use.
(Linux, cygwin, Solaris, FreeBSD, Mac OS X that is).
And here the uphill bottle started:
subversion requires the apache runtime. No problem I got APR. The apr -
well this
beast is giving you a hell lot of trouble. I don't want to have the
usual dynamic library
proliferation. I don't want to have to worry about them. I prefer to
spend my time on
more interesting things that managing the system. But apparently for
some no sane reason
the configure script didn't honor --disable-shared. Shrug. Poor quality
sign.. Then I had
to discover that subversion needs apr-util - whatever it may contain.
apr-util wants expat
gdmb ldap and about 10 other subsystems I didn't care to count. Sorry
but I like to know what thoes are supposed to be for? OK welcome to the
modern "free software hell". You won't
one thing - you get 100 other things to install before you can even try
to use it.
Fortunately it was possible to compile this thing with some tweaks.
However most of the
dependencies couldn't be specified. The thing just went on to look for
them no matter what I told it. Didn't find much of the things already
present in the OS. That much about a reproductible setup... Down the
bin it is.
subversion setup itself was no better. mod_apache_blah/perl/python/ruby
and what a not...
Wonderfull I was only missing a requirement on PHP and VisualBasic. But
I just want to have
a source code management system.
Finally of course I was able to resolve those problems. But the
questions remain:
1. What do I have? Which *kind* of subversion do I have? Checkouts seem
to work
but which "feature" do I miss?
2. Can I just move the executable to a different box? Which hidden
setup dependencies
does it include?
3. Which "important" feature do I miss in my subversion?
4. Aborting a checkout didn't work properly. The thing didn't notice I
plugged the
network connection.
5. The client didn't handle signals properly (^C). It was trying for
ever to finish a
transaction it should abort.
6. Seeing problems 4. and 5. in the client I don't even want to have a
look at the
server - I already know up front that there will be enough problems
with it.
7. There seemed to be no compression mode for the checkout.
Anyway as a summary - down it to the bin:
There is no such a thing as subversion - there is a bunch of very
different applications
compiled from the same source code out there posing as a single one.
Maybe I'm getting old but this kind of library or scripting language
creep is something
that in my experience is always giving me a big warning about overall
design quality.
If a thing, which should serve just one purpose, namely source code
managment, is
showing that it tries to be everything to everybody, then the red alarm
lamp goes on for
me. With that much dependencies on particular external things there is
a guarantee that
this kind of software can't have any quality assurance - because there
are too many
variations you would have to test. Why do we use C after all? Mainly
because it doesn't
change. But whom I'm telling thins.
And experience shows that such a beast is very likely to give you over
time a lot of the
typical software deployment problems consultants make a living from.
Just look at the ToDo
list they have. It's certain that over the long time line they will be
happy implementing
bazilions of things suddenly releasing some kind of subversion 2.0 and
then finally
abondoning the 1.1.x half done series with the requirement to use some
crafted at the late
our perl script for repository migration, which is in reality only
working for the "hello
world" project, to the shiny new subversion 2.0. Seen that done that.
But I think the
problems of CVS don't justify taking such burdens and risks. However
it's very likely that
this kind of source code base will simply stop developing in a not too
long time frame - no
developer will be capable to even moderately test out any king of
changes to it very soon.
Thus I don't recommend changing repositories: subversion isn't going to
be better
then CVS over a medium time frame. It is just going to be less stable
secure and giving you
much more trouble if working in an environment different from the JBLD
(Joe's Bloated Linux
Distro).
Better stick with CVS - at least the problems are known and there are
no new problems
to occur over the long term. Testing SVN out right now may turn out
positive but for GCC
I think you have to think in decades and I seriously doubt that over
the longer time frame
subversion will "take over the world".
Just my 2c for whatever it may be worth. This list seems to be a gang
of "old boys" anyway,
so please excuse me if I was sounding like "preaching to the chorus"...
If you feel offended please excuse me bothering your time and ignore
it.