dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

> >> 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.
>
> I assumed you would say that, hence I didn't suggest it earlier. However
> there is another option: not pushing the repo with *all* the branches to
> Bitbucket, but keeping it (read-only) on the FEniCS web server, so
> anyone who would like to import and continue working on their feature
> branch can pull it from there instead of migrating themselves.

Yes, the plan is to store all possible data there. The bzr and git
branches for all the repos at the time of conversion, including all
the scripting that went into it.

> >>> 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.
>
> That's doable. We could even define a cut-off point (like 60 days) for
> which to keep the references and remove everything prior to this point.

ok. I think we can just strip without the cut-off point.

> > 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.
>
> I'd advise against doing the rewrite at a later point. We could only do
> it for OP2 because we were in a much more "controlled environment" where
> we knew all the contributors.
>
> Would it then make sense to use the 1.2 release as the base for the
> conversion for all FEniCS components?

No, there have been fixes made to trunk since, like removal of meshes,
generated code, downloading scripts etc.

--
Anders