fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

PS: Martin, can you turn off HTML? I can't really read your emails.

--
Anders


On Fri, Mar 22, 2013 at 10:03:47AM +0100, Martin Sandve Alnæs wrote:
>   >
>   files
>   [2]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
> Referenser
>   1. mailto:logg@xxxxxxxxx
>   2. https://github.com/jedbrown/git-fat/blob/master/test-retroactive.sh