fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Which solution is that? :)

I just checked the lp:ffc repo, we have 58 MB in ffc/test/, 46 of which is
.h files, 2.6 MB .json files, 1.8 MB .out files.

But the .bzr directory is only 44 MB, so I guess the compression ratio is
pretty good for the generated code (most of it doesn't change much).

If we archived the current ffc repository for archeologists, and stripped
old generated code references but kept adding new references, there would
be little to gain.

There are some MB to gain by reducing the size of the P5tet element code,
if someone feels up for the task :)

The biggest gain would come from making a more careful selection of
references, as there's a lot of duplication here (and still far from
perfect coverage). In particular, generating element code shareable between
forms like I did with sfc would give a massive reduction in total .h size
here.

Martin


On 22 March 2013 09:55, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:

> On 21 March 2013 22:37, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Thu, Mar 21, 2013 at 09:15:24PM +0000, Florian Rathgeber wrote:
> >
> >>> Those can be built (with a lot of effort) using the tarballs, and
> >>> the converted unchanged repository as well as the present bzr
> >>> repository will be stored for eternity on the web server.
> >> I'm not sure I understand what your plan for the clean-up is: I was
> >> assuming you want to take the opportunity to purge accidentally
> >> committed files, large binary files or generated files that should
> >> have never been committed in the first place etc.
> >> However all of this should not affect the ability to build old
> >> versions of FEniCS tools: I would advise against cleaning out old
> >> files which were legitimately committed at the time and simply became
> >> obsolete and were removed again later. Git is really good at
> >> compressing text files.
> >
> > The files I've put up for removal are meshes and generated code, some
> > of it quite large.
> >
> >>> 3. Get comments from Florian or anyone else interested in merging
> >>> in converted repos on the Git side.
> >> I'm hoping git-fast-filter [1] will do the trick. If not it'll require
> >> a bit of hackery. I'm not very worried about our FFC branch (I'm
> >> comfortable rebasing it on whatever final repository), but ideally I'd
> >> like to not slam the door in the faces of all those having feature
> >> branches lying around (Andre?).
> >
> > Can anyone with a feature branch comment on this issue? Will you want
> > to convert it to Git, then merge. Or are you happy to clone a fresh
> > branch on the Git side, then patch your changes manually?
> >
> >>> 4. Get comments from developers on the list of proposed files to
> >>> be deleted from the history.
> >> See my comments above: don't be too radical, only get rid of things
> >> that shouldn't have been there in the first place.
> >
> > Here's the list again for reference:
> >
> > https://gist.github.com/alogg/5213171#file-files_to_strip-txt
> >
> > The simple version is that the list contains the following:
> >
> > - .h if generated
> > - .xml.gz
> > - .inp
> > - .stl
> > - .data files
> > - the old manual with figures, tex, pdf
> > - some big autotools files
>
> I have no problems with these files being removed, for the reference
> files in FFC I think Martin's solution sounds good.
>
> Kristian
>
> > --
> > Anders
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~fenics
> > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fenics
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>