fenics team mailing list archive

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

On 22 March 2013 09:06, Anders Logg <logg@xxxxxxxxx> wrote:
>
> On Fri, Mar 22, 2013 at 12:58:43AM +0000, Florian Rathgeber wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >> On Thu, Mar 21, 2013 at 11:06:14PM +0100, Martin Sandve Alnæs
> >>
> >>
> >> By this argument, there isn't much we can remove.
> > How about using git-fat to handle large files that we don't want in
> > the repository, but still be able to pull in on demand? Jed has a
> > recipe for filtering an existing repository and taking a list of files
> > to be handled by git-fat:
> > https://github.com/jedbrown/git-fat/blob/master/test-retroactive.sh
>
> For me as a newcomer to git, it seems like an extra complication, and
> the problem is not that we have a bunch of files which are very
> large. It's more that we have very many files of moderate size that we
> generate and these change frequently. Furthermore, we can only a apply
> a filter to a few of these files so we would need to list them
> manually.
>
> It seems there a differing opinions on a few matters:
>
> - Should we care about conversion of branches?
>
>   My opinion is yes. There are quite a few active branches on
>   Launchpad, more than I had thought.

Agree.


> - Should we strip files from the history? Or just leave it as it is?
>
>   My opinion is yes. We will archive the full repository on the web
>   page and possibly some archive site so that historians can go back
>   and excavate the history in full detail.
>
>   It needs to be discussed exactly which files to remove. See earlier
>   post for a suggestion.

Ok by me in principle, with some caveats.


> - Should we remove meshes from the repository?
>
>   My opinion is yes. The meshes have already been removed and
>   a working system for easily downloading the meshes is in place.
>   This system will encourage the use of more interesting meshes (since
>   they no longer need to be very small) and will encourage
>   contribution of meshes to the gallery on the web page.

We currently have 3 MB of .xml.gz files eacho in data/ and demo/, and 48 KB
in test/. Small(!) meshes used by the unit tests should definitely be kept,
for test coverage of e.g. mesh reading. Data not used by demos should
definitely be moved. With meshes used by demos we run into versioning
problems if they are removed.


> - Should we remove generated code from the repository?
>
>   Martin has some good arguments in favor of keeping the generated
>   code, but I'm not fully convinced. A compromise would be to include
>   all files needed to build the library itself, which essentially
>   means keeping the generated code in dolfin/ale.

I think the compromise is good and important, since it essentially means
keeping the dolfin library build ffc-independent. Having ffc generating
fresh code for C++ demos regularly has advantages as well.

>   But does that mean we should also keep all the old generated code
>   that was part of the library at some point?

I personally don't care a lot about code archeology, as long as we have
fairly recent history available for debugging. Is it feasible to pick a
date and strip before that? E.g. stripping generated code from before the
1.0 release?

Martin