fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21/03/13 20:58, Anders Logg wrote:
> On Thu, Mar 21, 2013 at 06:52:58PM +0100, Johan Hake wrote:
>> Nice work! So this is how git get so fast, we first remove all
>> the large files ;)
> 
> Yes, exactly.
> 
> I didn't think it would be such a hassle. I was imagining a simple 
> conversion (which took just a few minutes to figure out), but then 
> suddenly we are in the git camp and need to rewrite our history to 
> present a beatiful repository to the world. :-)

See it the other way: we now have the *opportunity* to undo some
mistakes/sins from the past.

>>> I have done some work on cleaning up the DOLFIN repository.
>>> 
>>> - All data files have been removed from the lp:dolfin bzr
>>> repository.
>>> 
>>> - All generated code has been removed from the lp:dolfin bzr
>>> repository.
>>> 
>>> - With the help of Jed Brown's git-fat, I have generated a list
>>> of files that I suggest we strip from the history (once the
>>> new conversion has taken place).
>> How will this affect the possibility to compile legacy versions
>> of dolfin to test for example speed ups? Are these done with
>> cached tarballs?
> 
> 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.

> What needs to happen now before we can make the transition is:
> 
> 1. Get the buildbot green again. It is broken as a result of some 
> renaming and removing of files that the buildbot needs to
> generate.
> 
> 2. Release 1.2.
> 
> 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?).

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

[1]:
https://github.com/mojavelinux/jbosstools-gitmigration/tree/master/git_fast_filter

Florian

> -- Anders
> 
>>> Please look at the files to be removed here
>>> (files_to_strip.txt):
>>> 
>>> https://gist.github.com/alogg/5213171
>>> 
>>> Btw, is there some equivalent of the Gist thing for Bitbucket?
>>> I found it very convenient for sharing the above data.
>>> Actually, I couldn't figure out any other convenient way to do
>>> it.
>>> 
>>> Garth is on his way to Australia, Florian needs some time to
>>> think about what this means for conversion of branches (like
>>> his FFC branch), Johannes is about to make a new release and I
>>> need feedback on the file removal. So the new message is to
>>> keep on working on the Launchpad repositories (with focus on
>>> cleanup and bug fixes) until this has settled, and I'll run the
>>> final script for conversion of the repositories again when we
>>> have worked out all the issues.
>> Sounds good. Johan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFLeGwACgkQ8Z6llsctAxYFjACeKuBiqyJqy14ZB2luUHBuRgEY
SXcAoM/MDCm47czNITH2G38jSWYGmRmR
=QZlA
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature