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 Fri, 2005-02-11 at 01:38 +0100, Marcin Dalecki wrote:
> 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.
> 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"

Uh, why do you want the server stuff for gcc purposes?

>  and creeping some 
> Java stuff in.
> Java -

These are java bindings, if you don't use them, don't use them.
>  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).

Uh, you could simply build it with --disable-shared if you really
wanted 

> 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.

> 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.
>  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.

> 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.

> 
> 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.

What do you mean?
You can happily abort a checkout and restart it later through hitting
ctrl-c.

> 
> 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),
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 

> 
> 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.
It *only* sends compressed texts, there is no need to pass extra
options.
This is actually explained in the manual.

> 
> 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?

Sorry, but you seem to just have gone looking for trouble and found it.
You didn't want to install perfectly working binaries, then you complain
that the source has dependencies! Of course it does. So does gcc.

Every program has optional things (in this case, subversion's apache
server module, database backend, and scripting langauge bindings) that
only are turned on if you have them.
Oh no, the configure script went looking to see if it could use already
installed libraries!
You complain you don't want the server mode, but then complain that you
are missing these features.
You hate shared libraries, and subversion has shared libraries.
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.
Subversion has a very strict development process in terms of when
compatibly will and will not be broken.Even moreso than gcc, which has
broken C++/libstdc++ compatibility at some level with every single
release.  CVS has done this as well over a number of releases.
It's also obvious you didn't bother to go looking at how they actually
develop it before ranting.

Please stop trolling
Next time you don't want to deal with configuring source, install the
binaries. 




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