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:l...@simula.no > 2. https://github.com/jedbrown/git-fat/blob/master/test-retroactive.sh _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
