RE: [Axiom-developer] build-improvements on cygwin

[Page, Bill]

On Tuesday, November 28, 2006 5:30 PM Ben Collins-Sussman wrote:
> 
> On 28 Nov 2006 23:16:38 +0100, Gabriel Dos Reis
> <address@hidden> wrote:
> > "Page, Bill" <address@hidden> writes:
> >
> > [...]
> >
> > | Up to revision 199 (October 26), the 'svk smerge' 
> > | transactions from the axiom-developer.org server that are
> > | intended to synchronize the Google repository with the
> > | SourceForge repository were properly processed by Google.
> > | For reasons that I don't understand, the svk smerge process
> > | did not automatically create the correct branch structure
> > at Google when we created 'silver' on SVN SourceForge.
> >
> > I believe 'silver' was created from "scratch", so has not 
> > ancestry in common with any other branch in the repository -- 
> > if my understand of your famous picture is correct.  It
> > effectively is a "repository" within the repository  --
> > essentially, files are _duplicated_ as opposed to being shared.
> > For me, that explains the sudden surge.
> >

I don't understand "repository within repository" comment but
yes I agree that the large increase in size in not unexpected.
In fact we discussed exactly this before the creation of 'silver'
back in October. Do you recall our discuss of the consequences
of having two roots in the repository?

For me, the mystery is why 'svk smerge' did not successfully
mirror our creation of this new branch.

> 
> Yep, that would explain it.  Branches are supposed to be cheap
> copies; they're just a hardlink within the repository, so they're
> nearly instantaneous to create and take essentially zero space
> when they're first made.  I don't know what you did on
> sourceforge, but it sure wasn't a normal subversion branch!
>

No it was not a normal subversion branch. Our problem has a long
history connected with different major Axiom developers using
different source code repository systems (arch, cvs and svn).
The original trunk in svn at SourceForge was created by the
SourceForge tool for converting cvs to svn. The contents of cvs
at SourceForge was obtained from a series of snapshots from the
arch master repository. Because of improperly flagged binary
files, the resulting svn repository was a bit of mess but that
was eventually corrected.

Meanwhile for a variety of reasons development continued on both
arch and svn independently with commits to both svn trunk and to
several svn branches as well as the original arch "silver". In
October we decided to try to merge the changes to svn trunk and
arch silver. My proposal was to automatically mirror the arch
silver repository as a new "trunk" on svn so that both sets of
developers could continue using their own repository systems.
This resulted in the duplication of files mentioned by Gaby.

To understand my motivation it is important to note that the svn
mirror of the silver repository contains the history of the
development in arch. While the existing trunk contains only the
snapshot history from cvs.

In mean time, we also implemented an automatic mirror process
that is supposed to keep the Axiom Google Code repository in
sync with the SourceForge repository. I guess in retrospect
creating 'silver' at SourceForge after implemented the automatic
mirror was a bad idea given that we are so severely limited in
disk quota at Google.

What I would really like to be able to do is "re-base" all of
the existing branches on svn on this new 'silver' so that they
are deltas of it instead of trunk. Then commits to the arch
silver master would still be properly reflected at SourceForge
and Google. But maybe this is a vane hope. And maybe the long
term continued use of arch is in doubt anyway.

To move forward, I think what we probably need to do is to replace
the trunk at SourceForge with the current contents of 'silver' at
SourceForge. I.e. compute the minimum delta from trunk to silver
and then apply it to trunk. And then scrap all of the history
related to 'silver' even though 'silver' actually has the more
complete history. I think we *might* be able to do this via
svnadmin at SourceForge... but I really need the help of someone
more knowledgeable than me in order to avoid yet another disk
space catastrophe.

> I can reset the google repository to revision 0 if you'd like.
> 

You may recall that more than this was necessary since the way
the svk smerge mirror synchronization process works it seems to
result in much greater disk space ussage then just 'svnadmin load'.
So just reseting it to 0 may not be enough. We went around this
problem several times before until you decided to use svnadmin.

Regards,
Bill Page.