fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

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

On 20/03/13 00:51, Anders Logg wrote:
> On Wed, Mar 20, 2013 at 12:16:09AM +0000, Florian Rathgeber wrote:
> 
>>> Anders, Garth and I sat down this evening to work out a
>>> migration strategy and I think we've arrived at something
>>> workable.
>>> 
>>> Just a few words of explanation about the pitfalls: Converting
>>> the trunk is relatively straightforward (and the conversion
>>> scripts should have finished by now), but we need to be very
>>> careful when migrating feature branches s.t. they keep the
>>> correct ancestry relationship.
>>> 
>>> Consider the following situation of a feature branch branching
>>> of trunk after revision 1803:
>>> 
>>> o trunk (r 1806) --> d9e67c2 | o  + feature-branch (r 1805)
>>> --> 16c0470 |  | o  + | / |/ o base (r 1803) --> dafb344 |
>>> 
>>> After converting trunk to Git, bzr revision 1806 becomes git 
>>> revision d9e67c2 and 1803 becomes dafb344. When migrating 
>>> feature-branch, it is *critical* that revision 16c0470 is a 
>>> descendant of dafb344.
>>> 
>>> For this to work, bzr fast-export needs to know which revisions
>>> it has already exported and git fast-import needs to know
>>> which revisions it has already seen (and both need to agree on
>>> that!). Therefore you need to have access to the *same* marks
>>> file that was used when converting trunk.
>>> 
>>> If it doesn't have access to this information when importing 
>>> feature-branch, fast-{im,ex}port will go ahead and do all the 
>>> conversion for revision 1803 and its ancestors *again* and you 
>>> will end up with *the entire history replicated* but
>>> *different* git revision ids s.t. git has no way of knowing
>>> that feature-branch should be a descendant of dafb344.
>>> 
>>> Anders will make all the marks files used for the conversions
>>> of the FEniCS projects available and we'll send detailed
>>> migration instructions for feature branches once all the
>>> infrastructure is in place. I've already sketched out how that
>>> is going to work: 
>>> https://gist.github.com/kynan/41b7e7f405ce38fa250a
>> We really need to make sure this is done properly or we'll
>> create ourselves a lot of work and headaches. I've had a chat
>> with Andy and I think he has a better idea of the differences
>> between BitBucket and GitHub than the rest of us. Is it worth for
>> the 4 of us have a (Skype/Google hangout) discussion before 
>> announcing it all publicly? There is also the question whether or
>> not you'd like to make/suggest some changes to the current
>> development workflow. Git differs from bzr in some way e.g.
>> branches are much more lightweight and therefore it encourages
>> branching much more often. Also git has very advanced history
>> rewriting capabilities so you could switch to a rebase instead of
>> merge workflow if you like.
> 
> Thanks to Florian for the great assistance.
> 
> The files needed to convert a branch which has a FEniCS component 
> trunk branch as an ancestor can be found here, together with the 
> script used to do the conversion:
> 
> http://fenicsproject.org/pub/software/git/bzr-to-git-conversion-2013-03-19/
>
>  We will store this data on the server for an eternity.
> 
> If you don't know what that means or don't care, you can ignore
> this message.
> 
> New Git branches of FEniCS components have been created here:
> 
> https://bitbucket.org/fenics-project
> 
> These should now be used as the main development branches.

I've written an automatic branch import script which should allow
anyone to import their bzr feature branches into the new git
repositories: https://gist.github.com/kynan/41b7e7f405ce38fa250a

To get it, in a directory on your path do:
$ wget
https://gist.github.com/kynan/41b7e7f405ce38fa250a/raw/import-branch.sh
$ chmod +x import-branch.sh

Let's take DOLFIN as an example (it works the same way for the other
projects) and assume you want to import the branch my-feature:

1) Clone the repository
$ git clone git@xxxxxxxxxxxxx:fenics-project/dolfin.git
$ cd dolfin

2) Import your feature branch
$ import-branch.sh dolfin /path/to/my-feature my-feature

3) Check that everything worked and the ancestry relationship is correct
$ git log --graph --all --decorate --pretty=oneline --abbrev-commit

4) Importing further branches should work also incrementally and even
after you've worked with the git repository *as long as you keep the
marks files* in .git/info/fast-import/dolfin.marks.{git,bzr}.

This should allow you resume working in git right where you left off
in bzr! Please let us know if there are any migration issues.

Florian

> -- Anders
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFJGqgACgkQ8Z6llsctAxZ8kACggJbtV66e9JVCTL7MhgvJr4B+
1wQAn0N9BkZp4bYb8tX+Ocohr714iK7g
=DUY7
-----END PGP SIGNATURE-----

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