fenics team mailing list archive

[Myles English <mylesenglish@xxxxxxxxx>]

Mainly just to clarify something I said earlier, as I am approaching the
limit of my knowledge on this subject.  Also, unless someone is willing
to try out the git subtree idea and enjoy the experience it won't go any
further anyway.

Martin Sandve Alnæs writes:

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

Git is commonly used to work conveniently with centralised Subversion
repositories.

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

The only reason for not mixing changes across components in one commit
is that the same commit message ends up in both repos (unless --squash
is used) where it may not make sense in that context.

> 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

Myles

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