dolfin team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

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

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

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

OK

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

OK

Florian

> -- Anders

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