fenics team mailing list archive

[Myles English <mylesenglish@xxxxxxxxx>]

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:

> On 20 February 2013 23:35, Anders Logg <logg@xxxxxxxxx> wrote:
>> On Wed, Feb 20, 2013 at 10:15:20PM +0000, Garth N. Wells wrote:
>>>> It seems to me there are essentially three groups that this suggestion
>>>> will affect in different ways:
>>>>
>>>> 1. Core developers who have to suffer the hassle of making multiple
>>>> releases

Scripts that work with lp API should solve this, as mentioned.

>>>> and working every day in multiple repositories.

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.

>>>> 2. Advanced users who want to pick and choose specific components.

The individual components would still be available in lp.

>>>> 3. Users who don't really care how the code is organized as long as it
>>>> can be installed easily.

Ubuntu packages would still be available from lp, source from github or
lp.

>>>> I think the suggestion will be a big relief for the group (1) of core
>>>> developers (5-10 people) and it will have a positive effect on the big
>>>> group of users (> 1000 people?) who don't need to worry about matching
>>>> version numbers. But it might be a small setback for the relatively
>>>> small group (2) of advanced users.

Core developers may not be happy about being forced to use git, or the
slightly increased complexity of syncing and maintenance.

>>> I'm still not fully convinced either way. I find the concept of nested
>>> repositories appealing.

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.

>>> How convenient it is in practice I don't know.  Would someone who
>>> has spoken in favour of nested repositories be wiling to make an
>>> example somewhere that we could test? I'm open to changing version
>>> control system if something else suits our needs.

>> Same here, but we're fairly committed to Launchpad and Launchpad does
>> not do git.

Launchpad would continue to be used under this scheme.

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

Myles