[Axiom-developer] Re: [M#73697383] Re: Disk-quota Request

[root]

> PS. On a related issue. The more I think about the 'zips'
> directory in the Axiom distribution the more I think it was a
> ReallyStupid (tm) invention. Why take a source code tarball from
> another project (gcl) and stick it into the Axiom repository?

I see your 'reasons' cache has expired again. 
Please refresh it from the mailing list history. :-)

Axiom is NOT the only one to do this and there are prefectly valid
reasons for doing so. Review your version of SVN if you don't
believe me. They include Neon and APR. 

You believe that yum and apt-get work and that they work for
every user. But consider all of the software that got installed
because you needed a couple Perl packages. I believe the number
was in the hundreds. I've run into the same issue trying to
automatically install yum packages. I generally abort the
update if it insists on installing a new version of glibc
when all i wanted was to bring some utility up to date.

And consider what happens when the average user tries to 
update the utility, the update insists on re-installing glibc,
and the user does not have root access.

Plus if you apt-get GCL you might get a version from stable,
unstable, or testing. Yet GCL-2.6.8pre only works on some
systems and GCL-2.6.8pre2 only works on others and there is
no build-time way to distinguish them. Nor is there a tag
so you can't pull from the CVS. I'm waiting to see how this
issue is handled in build-improvements.

Axiom build should 'just work'.

Not, 'just work if you have yum', 'have root access', and
'are willing to install a hundred Perl scripts' or 'know
which CVS tag will work with this axiom version'. Axiom 
can build on Red Flag Linux. As far as I know they don't
have either yum or apt-get (or if they do I don't know the
chinese incantation). Axiom is nearly working on the MAC.
As far as I know there is no yum for the MAC.

Axiom build should 'just work'.




> If we really need a copy of gcl, why don't we just add it properly
> into the repository as source code? Why do we work around the
> capabilities of the source code control system by saving the
> tarball and patches against it, having to apply these patches
> during the build instead of just committing these patches to
> Axiom's version of gcl in the repository? All of this stuff is
> stored in the repository in a compressed manner anyway, right?

The reason to use the GCL tarball with patches is that gradually
the patches get accepted upstream. If we copied the source tree
into Axiom we would be maintaining our own version which would
eventually get out of sync. A source tarball with patches does
not get out of sync since the patches are obvious.

The fact that the repository is or is not compressed has nothing
to do with the whole issue.




Part of your frustration seems to be coming from SVN. I'm using
SVN in work and it 'locks' the source tree, insists I run 'cleanup'
(which NEVER works), and forces me to unwind changes, blow away my
source tree, refetch the repository, re-apply my changes, and commit.
It is tedious. The whole idea of 'locking' is broken.

I also use SVN on Magnus, one of my other open source projects.
The checkouts regularly fail. I have to do a checkout followed
by at least a half-dozen 'updates' to get a good source tree.
And then commit bombs and I'm forced to try to clean up the
resulting mess using the same dance of 'back-out, blow-away,
checkout, update, update, update, update, update, update,
apply changes, commit and pray.

Darcs is slow but it works. 
Arch is complex but has never failed.
CVS is old but never fails.

SVN is broken. Face it. It's not ready for prime time.
The only hope we have is to host it ourselves so you can
use the admin tools to recover.

t