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 02:19, Daniel Berlin wrote:
Uh, why do you want the server stuff for gcc purposes?
Just curious. Why not? If I want to try it out I want to try it out on
my own
repos too. Maybe I was just too optimistic about it. And then I simply
didn't know up front what I will get - just the client the server or
what else
ot of it. configure --help didn't tell anything about it.
These are java bindings, if you don't use them, don't use them.
They are there. They have to be supported maintained and so on... they
may break things if I suddenly update something on the system...
And don't tell me this isn't going to happen. I did already enough
oracle
installations in my life to get always nervous if I hear the word
Java...
Uh, you could simply build it with --disable-shared if you really
wanted
No this certainly didn't work. It was still building the shared stuff.
No problem I got APR. The apr -
Fortunately it was possible to compile this thing with some tweaks.
With some tweaks?
It should compile out of the box on osx. I've done it before.
The emphasis is on should...
However most of the
dependencies couldn't be specified. The thing just went on to look for
them no matter what I told it.
Having built apr many many times, i've never seen this problem.
So look closer... Try disabling ldap: --without-ldap will give you a
link
error for the library named well: "no".
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...
It requires none of these things, it simply checks fo them, and will
build bindings if you like.
So I would like to be able to disable stuff I don't need. Nothing there
- no
chance of something to be broken. (The perfect error free code - the
null code
doing nothing!)
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?
In the end, you have the same thing you would have gotten from a client
install.
No I like to know what I get. I like to know what the application
contains
what it is supporting and so on. This can't be established for a naive
compile
relying on configure scripts which have broken --disable-xxx or
--without-xxx directives.
Call me pedantic. But this is what you get too if working long enough
in security
sensitive environments. Maybe I'm not the windows generation which
didn't grow up
with the impression imposed on them that crashing software is something
ethernal
to life...
What do you mean?
You can happily abort a checkout and restart it later through hitting
ctrl-c.
And now imagine you don't have an 1G connection working 24/7. Just
start the
command and plug the LAN from you computer and watch svn never noticing
this.
Press ctrl-c and watch svn never timing out... Good test for poorly
written
software btw.
5. The client didn't handle signals properly (^C). It was trying for
ever to finish a
transaction it should abort.
For the database based server backend (not the filesystem based one),
A ha! There are multiple application which are posing as
subversion-server. So what is
a subversion server? Which "backend" did I get during the configure
process? Which backends did I get I never wanted to have? Wondering why
this makes me nervous? Well maybe I did already see too much CERT
anouncments in
my life...
the stupid database library will require aborting the transaction if
you
an abort a transaction, even if it is a readonly one, So it will only
let you abort an operation at certain times. Against our server, it
doesn't matter, so you can control-z and kill it.
Hoewver, please not that control c'ing cvs at the wrong time will cause
repository corruption as well. Subversion just doesn't let you do it
during the small time windows where
A ha! Apparently the word transaction wasn't in the dictionary out
there?
Again poor quality for a new design. If a backend isn't as "secure" as
another
and could cause things to break or even work differently. Well it
shouldn't
be a back-end in first place at all.
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.
You just provided "internals" information which tells me that the
speculation
was right.
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.
What are you talking about?
I am talking about the fact that it wasn't possible to control the
feature set
of this application. Thus you have a single source base which you can
use to compile very different multiple applications. But you have a
single
application at hand.
You didn't want to install perfectly working binaries, then you
complain
that the source has dependencies! Of course it does. So does gcc.
No I have no problems with the dependencies I have a problem with:
1. The number of them.
2. The feature disease exposed by them.
3. The fact I couldn't *controll* them during software setup in an
aceptable way.
Every program has optional things (in this case, subversion's apache
False. The null program without any features has no optional things
(QED).
server module, database backend, and scripting langauge bindings) that
only are turned on if you have them.
That is an opinion but not a fact statement based on too much
time spend in front of a linux distribution. Usually it's very well
defined
what an oracle DB or a C99 compiler for example is. There are whole
organizations
doing just this - defining what things are meant to be...
Oh no, the configure script went looking to see if it could use already
installed libraries!
No it was using this information to enable and disable features.
Features I didn't want to have. Features I wanted to have control over.
You complain you don't want the server mode, but then complain that you
are missing these features.
No I complain that I get those features without the ability to CONTROL
whatever
I want them or not.
You hate shared libraries, and subversion has shared libraries.
I don't hate them! Don't put me words in the mouth.
But yes I just see too much software using them just out of
a sudden without good measure whatever it makes technically sense or
not.
This is always a hint for the fact that the person in question didn't
have sufficient competence to even know about the trade offs involved in
something as trivial as such an simple decision. Why should I then
assume he will
be competent in areas more demanding?
etc
Nothing in the rest of your message really has to do with subversion,
Just a rant about how you think about software development models.
Yes and I came to the conclusion that subversion isn't an example of a
good well developed product sufficiently well done to be good enough
base for something as endurable as the GCC. Yours millage may vary.
Basically I was warning here that the usability test isn't the
only thing you have to assess before taking decisions about something
like
a source code management system to be used. And well I permitted myself
to
give a cast on the darker corners of it.
Subversion has a very strict development process in terms of when
compatibly will and will not be broken.Even moreso than gcc, which has
I don't rely on promises. I rely on what I see, because I suffered
already
enough from those promises...
broken C++/libstdc++ compatibility at some level with every single
release.
So what? It wasn't a nice experience then. Would it be good for the
repository now?
CVS has done this as well over a number of releases.
The last time it did is already very very long ago... I think
it was years before subversion even existed.
It's also obvious you didn't bother to go looking at how they actually
develop it before ranting.
Look something has to be good in every piece to be good overall. But
it's
sufficient to be killed once to be dead.