Boost logo

Boost :

Subject: Re: [boost] [git] neglected aspects
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-02-09 09:10:13


Hi,

> Stop right here. You seem to be writing this on the assumption that
> with git, we'd still have two separate source trees, one for the
> development branch and one for the release/master branch. One of the
> exciting things of git is exactly that you can abandon that situation.
> There is only one file tree, and the branches act like "parallel
> worlds" in which that same file tree received different update
> histories. So a feature branch is just another instance of the same
> tree, with the same available testing infrastructure.

For me branches in SVN match perfectly the git version you provide.
When you create a branch it's the same "file tree" and then you can
apply different patches on both (and then merge them back). Of course
if the patches are add or remove files then file trees will differ,
but I guess that this is the same for git. The differenc I see is that
branches are a separate entity while in SVN they're a different leaf
in the node above.

> - The master branch corresponds to the current release branch, again
> with an important difference. In the current situation, trunk is
> merged directly into release, with the (manual) exception of libraries
> that are in too turbulent state, and after that the release branch is
> updated until everything is really ready for release. In the new
> situation, a new (temporary) release branch is forked from develop
> first (which automatically excludes turbulent changes because those
> reside in separate feature branches) and then updated until all tests
> pass (ideally), at which point it is finally merged into master (as
> well as back into develop). So the master branch only includes the
> actual releases, which of course are also tagged.

This doesn't fit in my small brain when I try to imagine it. Sorry :(
I guess it's time people on both sides fire their slide editors so that I
(and hopefully others) can have a better view of the problem and
the solutions

Julien


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk