← Back to team overview

dolfin team mailing list archive

Re: Notification from dolfin-kth repository

 

On Thu, Oct 26, 2006 at 01:16:27PM +0200, Johan Jansson wrote:
> We had an idea to create a branch of DOLFIN where we could work on
> (and break) the mesh while still keeping a more stable DOLFIN branch
> with the old mesh. Now it turned out the other way around, the mesh
> was replaced in the main DOLFIN branch while the new branch was kept
> stable. Anyway, I think it has worked rather well to have two
> branches, high-level development has been able to continue in the
> stable branch, and kernel development has been done in the main
> development branch.
> 
> Notifications from the stable branch (called "dolfin-kth") have not
> been sent to this list though. I've turned that on now. There have
> only been a few changesets, you can view them here:
> 
> http://www.fenics.org/hg/dolfin-kth
> 
> Please comment if you have ideas how to organize the branches, if we
> should have two branches inside the same repository (doesn't work so
> smoothly with Mercurial in my experience), or whether we should have
> separate repositories (even more than two perhaps).
> 
> Starting/cloning a repository is so simple in Mercurial (everyone has
> a private repository anyway when they develop), so I think it's
> natural that every repository represents a branch.
> 
>   Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

I'm not so sure I like the branched development we have now with a
separate dolfin-kth. The consequence of this development is that the
core development takes place in the main dolfin tree (mostly by Garth
and myself), while you work on your own things in dolfin-kth.

If you instead worked in the main dolfin tree, you would be forced to
keep up with and contribute to the development of the core
functionality which I would like better.

I think separate trees should be something that we create temporarily
for testing and implementing new features before merging back into the
main tree. It should not be something permanent since it would then in
practice be a fork.

/Anders


Follow ups

References