dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Mar 27, 2013 at 03:23:53PM +0000, Florian Rathgeber wrote:
> On 26/03/13 22:32, Anders Logg wrote:
> > On Tue, Mar 26, 2013 at 09:57:00PM +0000, Florian Rathgeber wrote:
> >> On 26/03/13 17:02, Anders Logg wrote:
> >>> On Tue, Mar 26, 2013 at 04:23:30PM +0000, Florian Rathgeber
> >>> wrote:
> >>>> On 26/03/13 16:11, Anders Logg wrote:
> >>>>> On Tue, Mar 26, 2013 at 04:04:27PM +0000, Florian Rathgeber
> >>>>> wrote:
> >>>>>> On 26/03/13 15:55, Garth N. Wells wrote:
> >>>>>>> On Tuesday, 26 March 2013, David Ham wrote:
> >>>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> I imagine that Florian will have something to say about
> >>>>>>> this, but the ffc pyop2 branch may be an issue here.
> >>>>>>> lp:~mapdes/ffc/pyop2
> >>>>>>>
> >>>>>>>
> >>>>>>> This may be fine because I don't believe that we're
> >>>>>>> planning to prune/rewrite the FFC history at this stage
> >>>>>>> (I think that it's required, but it's easier to delay
> >>>>>>> until later compared to the DOLFIN repo). We need
> >>>>>>> Florian to tell us if this will work.
> >>>>>>
> >>>>>> As I mentioned earlier there is also the route of
> >>>>>> importing the feature branch into the non-filtered
> >>>>>> repository (where the marks files are "intact") and then
> >>>>>> transplanting the branch (with all its history etc.) to
> >>>>>> the rewritten repository via a git rebase. It's a bit
> >>>>>> more laborious and you should know what you're doing, but
> >>>>>> I've done it before. We've rewritten both the OP2 and
> >>>>>> the PyOP2 repositories halfway through the project. It's
> >>>>>> just not something I would want to ask a git novice to do
> >>>>>> by themselves.
> >>>>>
> >>>>> I would say it's up to you. I don't care much about the
> >>>>> history of feature branches and no one else has indicated
> >>>>> that it is important to provide a route for converting
> >>>>> feature branches. So if it is important to the ffc/pyop2
> >>>>> branch, I can follow your instructions.
> >>>>>
> >>>>> But I would assume that requires merging the ffc/pyop2
> >>>>> branch *now*, before the conversion, and it might not be
> >>>>> ready?
> >>>>
> >>>> No, I can do that later. The reason the branch isn't quite
> >>>> ready is that we don't (yet) have tests for the features
> >>>> we're adding so it would be hard for the FFC developers to
> >>>> notice if they break anything for us post merge. We're
> >>>> passing the existing FFC test suite though.
> >>>
> >>> ok. So is it ok for your branch if we just do the conversion
> >>> without the marks files?
> >>
> >> Having the marks file will definitely speed things up in case
> >> we're not rewriting FFC. But if we're deciding to filter FFC and
> >> therefore invalidate the marks files I can do without, yes.
> >
> > ok. So from what I've heard so far, it seems there are really no
> > strong objections to converting to git in combination with
> > stripping, and forcing all branches to start from scratch on the
> > git side.
> >
> > I wouldn't mind making it easier to transition feature branches,
> > but it seems very difficult to do so.
>
> Yes, I still haven't found a satisfactory solution that is safe in all
> cases. The only safe solution I can think of at the moment is:
> 1) bzr -> git convert trunk with export of marks files
> 2) import *all* feature branches
> 3) filter the entire history, removing files we don't want
> 4) archive the new git repo with *all* branches on the fenics
> webserver with public read-only access
> 5) push only the master branch (bzr trunk) to bitbucket
> 6) instruct people how they can fetch their feature branches into
> their own (local) clones and then push to their own forks

What exactly does it mean to import all branches? Will it somehow
affect repository that we put on bitbucket?

> I've asked a question on SO, maybe someone has an idea:
> http://stackoverflow.com/q/15660467/396967
>
> I'm currently discussing with Jelmer on #bzr: There's yet another
> conversion route using bzr dpush and/or bzr serve --git. That doesn't
> seems very promising either though: it's mostly designed to allow
> contributing to git projects using bzr (and we want the opposite).

ok. My main take on this right now is that I haven't heard anyone
saying that it's important to convert the feature branches, so I'm not
going to spend a lot of time thinking about it. :-) But as before, if
you come up with a good solution, I wouldn't mind.

I've moved the conversion script from the old gist to bitbucket. The
plan is to use this script to do the conversion:

https://bitbucket.org/fenics-project/fenics-bzr-to-git-conversion-2013

This should happen next weekend.

--
Anders