Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-05-08 15:32:50

2013/5/8 Beman Dawes <bdawes_at_[hidden]>

> On Tue, May 7, 2013 at 12:36 AM, Dave Abrahams <dave_at_[hidden]> wrote:
> >
> > on Mon May 06 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
> >
> >...
> >> One more precise question: Are we still planning to map trunk->develop
> >> and branches/release->master?
> >
> > Presently, as you can see, the mapping is trunk->master and
> > branches/release->release.  It could be easily changed, and I think that
> > might be a very good idea because otherwise we have to do a bulk branch
> > rename, which could cause havoc with developers.
>
> Strongly agree.
>
> We had previously agree to follow the Git Flow conventions, and so map
> trunk -> develop and branches/release -> master. It doesn't matter
> that the current mapping can be easily changed - the conversion isn't
> ready for prime time until that is done.
>

I am not opposed to master/develop. In fact, I am much in favor for Git
Flow.

The concern that I have with our current "release" branch is that it does
not correspond to "master" in the Git Flow model.

In Git Flow, you create a temporary release branch for stabilization. When
the stabilization is completed, you

1. merge to "master",
2. merge to "develop",
3. create a tag, and
4. drop the release branch.

In the end, "master" is stable at any point in time.

However, in SVN we currently use "release" as "release preparation" or
stabilization. This branch was not always guaranteed to be stable back in
history.

If we want to have a branch that corresponds to "master" in Git Flow, we
need to artificially recreate it based on the tags. This is certainly not
impossible, but requires further work.

-- Daniel

OTOH, I'm not so worried about having some extra branches. It seems
> reasonable to ask developers to clean out unwanted branches. If you
> can clean out the empty ones, fine. Likewise for branches that have
> seen no activity for years. But I wouldn't want to delay the
> conversion waiting for such niceties.
>
> --Beman
>