fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 28, 2013 at 09:28:13AM +0000, Florian Rathgeber wrote:
> On 28/03/13 06:35, Anders Logg wrote:
> > On Thu, Mar 28, 2013 at 02:46:49AM +0100, Roland Siegbert wrote:
> >> On 03/27/2013 10:40 PM, Anders Logg wrote:
> >>> On Wed, Mar 27, 2013 at 03:23:53PM +0000, Florian Rathgeber wrote:
> >>>> On 26/03/13 22:32, Anders Logg wrote:
> >>>> 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?
> >> It will include all branches directly instead of splitting it in a two
> >> step procedure with the filtering in between the two steps. As far, as I
> >> understood the discussion, that's a better solution than filtering the
> >> trunk/master branch - to get rid of the obsolete files - and attach the
> >> branches afterwards using some kind of yet unknown git voodoo.
> >
> > It still seems very strange to import all branches, considering most
> > of them will likely never be merged and perhaps only a couple of them
> > are ready for merge.
>
> I wasn't suggesting that: see 4) and 5) above: the repo with all
> branches is only for archiving on the FEniCS web server. Only master
> (formerly trunk) will be pushed to BitBucket. And if someone comes back
> in 2 years and wants to continue working on their feature branch, we
> point them to 6).

I think if they come back in 2 years, we should instruct them to start
from scratch.

> >>>> I've asked a question on SO, maybe someone has an idea:
> >>>> http://stackoverflow.com/q/15660467/396967
> >>
> >> I suggest like the following as a first draft for the conversion script:
>
> That is pretty much exactly what my import-branch script does :)
>
> >> <code>
> >> mkdir dolfin.git
> >> cd dolfin.git
> >> git init --bare
> >>
> >> bzr fast-export --export-marks=../marks.bzr ~/src/dolfin/master \
> >>    | git fast-import --export-marks=../marks.git
> >>
> >> <repeat n-branches-times:>
> >> bzr fast-export --marks=../marks.bzr --git-branch=<branchname> \
> >>    ~/src/dolfin/<branchname> | git fast-import \
> >>    --import-marks=../marks.git --export-marks=../marks.git
> >> <endrepeat>
> >>
> >> #As soon as this is done: Filter the history as planned, test it and
> >> then upload it to the new location:
> >>
> >> git remote add <bitbucket repolocation>
> >> git push --all # push all branches
> >> </code>
> >
> > That would create a repository on bitbucket containing all the
> > branches. I don't see why we should push anything but trunk.
>
> Yes, I agree, only trunk should go to BitBucket. Replace the final 2
> lines by:
>
> rsync -a . fenicsproject.org:/path/to/archive/dolfin.git
> git remote add origin git@xxxxxxxxxxxxx:fenics-project/dolfin.git
> git push origin master
>
> And repeat the process for all the other FEniCS components...

ok.

> > And still no one with a feature branch has claimed that it would be a
> > problem to start with a fresh clone. The only thing we would lose
> > would be the history of the feature branches.
>
> That might be because they're not reading this list and aren't even
> aware of the migration plans.

Perhaps...

--
Anders