fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Some thoughts I have now on the different aspects:

- A workflow that mixes two revision control systems is not sustainable.
It's bound to cause more problems than it solves. In particular considering
that most fenics developers prefer not having to learn the details of a
single system.

- Releases are not a big problem either way. Releasing more often will
reduce the per-release cost of blueprint and bug management, and allow
Johannes to keep the release process automated with lp scripting. If we
want one release for users, we can have that without repository change by
just checking out all current projects into a fenics/ directory and making
a tarball of that.

- If a good workflow with the unified repository requires not mixing
changes across components in one commit, I don't see any gain at all,
that's how it always is today. What we can not do without a unified
repository is commits that span multiple projects, for interface changes
that do affect multiple projects. If that's inconvenient to do, a unified
repository is worthless from my point of view.

- I think the two-way split (keeping dolfin separate, joining at least
ufc-ffc-ufl) sounds most compelling and carries less risk.

- The way I see it now, the main backside of the unification (assuming a
two-way split) is the complexity of backporting bug fixes. Worst case
scenario there is having to do manual patching, but it may be easier and we
don't do that much backporting.

Martin


On 21 February 2013 18:47, Anders Logg <logg@xxxxxxxxx> wrote:

> On Thu, Feb 21, 2013 at 12:11:29PM +0000, Myles English wrote:
> > Hi Garth,
> > Having piped up about 'git subtree' I feel implicated in this discussion
> > but can't commit any more time to it for the next couple of weeks,
> > sorry.  Some caveats I should point out, 1) I am not a fenics developer,
> > 2) git is familiar to me and bazaar is not, 3) most of what follows is
> > theory.
> > One solution, is that the project is kept unchanged on launchpad (lp)
> > and mirror the repositories on github.  The OpenStack project has done
> > this, they have 35 components, and they have a simple script to sync
> > git<-->lp, I have no idea if they like that setup or not.  Maybe the
> > increased complexity is worth it for 35 components but would not be for
> > FEniCS.
> > Garth N. Wells writes:
> > Scripts that work with lp API should solve this, as mentioned.
> > Git subtree should solve this.  You could work everyday in one repo and
> > split the changes back out to the individual components before making a
> > release.  One change in workflow is that it is better not to mix changes
> > to more than one component in the same commit.
>
> I'm not sure that's what we need. The point of the proposed change is
> to make it easy for developers to work on 'fenics' without having to
> worry about syncing and merging with multiple sources.
>
> > The individual components would still be available in lp.
> > Ubuntu packages would still be available from lp, source from github or
> > lp.
> > Core developers may not be happy about being forced to use git, or the
> > slightly increased complexity of syncing and maintenance.
> > Florian said that nesting bazaar repos is not feasible.  The git subtree
> > approach is not quite the same concept in that you just work with one
> > repo, and push to the component repos when ready.
> > Launchpad would continue to be used under this scheme.
>
> I wouldn't mind changing from bzr to git but the point of a change
> would have to be to make things simpler, not more complex.
>
> >> Hopefully there is a volunteer to show us how it would work with
> >> nested repos. It would have to be pretty compelling to contemplate
> >> moving from bzr (Launchpad supports automated import from other
> >> version control systems).
> > I have made a start, this is how to set up a local UFR using
> > git-subtree:
> > Install git-bzr-ng and git.
> > # make git repos, this is quite slow
> > mkdir ~/tmp/fex
> > cd ~/tmp/fex
> > ${BZR_REPOS}=~/path_to_bzr_repos
> > for i in dolfin ufc ufl ffc viper instant; do
> >  git bzr clone ${BZR_REPOS}/${i} ${i}
> > done
> > # make UFR
> > mkdir ~/tmp/fenics
> > cd ~/tmp/fenics
> > git init
> > echo "Needs an initial commit" > README
> > git cim "Added README"
> > # import all the components to the UFR as subtrees
> > for i in ufc ufl ffc viper instant dolfin; do
> >    git subtree add --prefix=${i} --squash \
> >                 ~/tmp/fex/${i} master
> >  done
> > Then do 'man git-subtree' look at push pull etc, which is the tricky
> > bit, I don't have time now to go any further.  I use git-subtree for
> > including a bibliography file and LaTeX style file that I use in lots of
> > different LaTeX projects and it works well.  I don't push the changes
> > back to the upstream repository that often, which is probably normal for
> > a library, and the most difficult bit is remembering the right command.
> > (Hmm, why is it that in seeking to simplify something it ends up looking
> > more complicated?)
>
> Thanks for the demo.
>
> --
> Anders
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>