[Axiom-developer] Re: the repository story (was: build-improvements on cygwin)

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> "Page, Bill" <address@hidden> writes:
> | How can we agree on a single host and a single repository system?
> | 
> | > ... 
> | > I tried to check where disk space go.  After looking at rsynced copy
> | > of SF repository I see that most space is taken due to following
> | > revisions:
> | > 
> | > 201   80 Mb  failed arcs clone ???
> | > 208   80 Mb  current 'silver'
> | > 252
> | > 219
> | > 143
> | > 115
> | > 102
> | > 31    each 20Mb -- snapshots of gcl-2.6.8
> | > 
> | 
> | 200-201 and 205-212 where both failed attempts. (I kept getting the
> | name wrong in the Tailor configuration file.) I finally got it right
> | in 213-218. Perhaps there are in fact 3 copies of the arch clone?
> | Or did I somehow manage to rename one and re-use it?
> |

AFAICS 208 was renamed two times: the final rename is 213.
 
> | How can I clean-up such mistakes without leaving this mess in the
> | repository?
> | 

I do not know how to clean SourceForge: it seems that their policy
forbids really deleting thing, so cleanup maybe impossible without
staff help.  OTOH svn allow you to retrive changesets, so it should
be possible just to "replay" reasonable changes and create a new
somewhat clean repository -- but still containing all gcl madness
(and a lot of other trash).

I am affraid that the best thing we can do on SourceForge is to
update 'trunk' and delete 'silver'.

> | Do you know the best way of merging 'silver' into 'trunk'? I think
> | you once compared these versions and said there was really very
> | little difference. Right?
> 

Yes. I would retrive changesets from 'silver' and apply them to 'trunk'.
Then I would delete 'silver'.  If you guys think that this is a good idea
I can do this. 

> diff compares files, not history or ancestry. 
> merge likes to have ancestry, so if you're doing star-merge and the
> branches don't have common ancestry, typically SVK/SVK will first
> delete then add (which you may think is silly but without ancestry,
> that is a reasonable thing to do).  That has the effect of
> "duplicating" files.
> 

Reasonable thing to do?  I am not sure (GITs pack command factors files
into deltas even if they do not have common ancestry).  But what you
wrote seem to explain part of disk usage.

> | Are we prepared to cut the automatic connection with Tim's original
> | axiom--silver--1? I believe Tim stated that he was no longer prepared
> | to maintain this branch anyway. So I assume "yes".
> | 

IIRC Tim statement was about SourceForge.  My understanding was that
he will put things in axiom--silver--1 when they are ready.

> | By 252 to 31 do you mean there are 6 copies of the gcl-2.6.8pre
> | tarball? I.e. 6 x 20 Mb = 120 Mb.
> 

Yes.  In fact, I think that we have 10 copies (giving us 5 or 6 versions)
of the gcl-2.6.8pre: the two copies of arch (201 and 208) probably
contain 2 copies (2 different versions) of gcl-2.6.8pre each.

> Do we do that before or after my changes I'm testing?  My changes
> means we now have gcl/ and noweb/ toplevel subdirectories, and the
> corresponding tarballs are gone; lsp/ is renamed to src/lisp.
> 

It seems that you did not commit your changes.  I belive that in
current sitation we should drop gcl from our repository and just
provide a script to fetch desired version form gcl repository.

I think it is time to start working on a 'dist' target for make.
I would imagine that such target should fetch dependencies and
build some files which may be problematic for users and that
pack everthing into a tarball. 

FYI I recently succesfully recreated 142 viewports (all used in
HyperDoc) and almost all .pht files.  ATM recreating graphic files
requires acccess to running X server.  Also, the whole process is
somewhat fleaky, depending on little details it works or fails
-- it looks like random memory corruptions.  

Also, I have a script that recreated many of book images.

-- 
                              Waldek Hebisch
address@hidden