This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]