dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

> But there is another option to get round the entire problem: simply
> importing *all* feature branches before doing the filtering. That
> should (unproven claim, I'll need to read the docs) be scriptable
> through the launchpad API and the branch import script that I've
> already written. But I was assuming you didn't want to necessarily
> migrate all the branches, so I didn't focus on this option in prior
> discussions.

That sounds like a very bad idea. I assume at least half of those
branches will never get merged.

> > For the FFC branch, I would like to strip out all the old .h
> > reference files. Then add them back again right after the
> > conversion.
>
> That is certainly doable, but so far my impression was that Martin
> objected to this plan?

We just made a release so I think we are quite comfortable that things
are working at the moment. If we pass all our regression tests
now. Then convert the repository, copy back the references, we should
not need to step back and look for errors introduced previous to the
conversion. I think what Martin objected to was moving the references
outside of the repository and I agree on that. So we strip the
repository from the references and do the conversion, then add back
the references.

Another option would be to wait with stripping data from the FFC
repository until a new a better test suite is in place, but that
requires going through this process again at a later time. I'd rather
have it done now and just move on.

--
Anders