← Back to team overview

fenics team mailing list archive

Re: Cleanup of repositories

 

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.

- 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.

- 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.

- 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.

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

--
Anders


Follow ups

References