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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
