Re: [boost] [git] [modular boost] Switchover schedule proposal

Subject: Re: [boost] [git] [modular boost] Switchover schedule proposal
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-10-30 00:17:11

Daniel Pfeifer <daniel_at_[hidden]> writes:

> 2013/10/29 Dave Abrahams <dave_at_[hidden]>:
>> Daniel Pfeifer <daniel_at_[hidden]> writes:
>>
>>> 2013/10/28 Dave Abrahams <dave_at_[hidden]>:
>>>> Daniel Pfeifer <daniel_at_[hidden]> writes:
>>>>
>>>>> 2013/10/27 Dave Abrahams <dave_at_[hidden]>:
>>>>>> Antony Polukhin <antoshkka_at_[hidden]> writes:
>>>>>>
>>>>>>> - Can I merge and delete branches in GIT without affecting the whole system
>>>>>>> stability (for example `conversion` library currently contains branches
>>>>>>> like `filesystem_V3`)
>>>>>>
>>>>>> If you're a library maintainer, yes.  The only branches that you must
>>>>>> maintain for system stability are "develop" and "master."  However, be
>>>>>> aware that some branches in the Boost super-project repository may be
>>>>>> referencing commits on your branches.
>>>>>
>>>>> Do we need all those branches in the super-project?
>>>>> If we drop everything but "develop", "master", and the release tags
>>>>> from the super-project, then library maintainers could clean up their
>>>>> repositories without being afraid of breaking something else.
>>>>
>>>> If we just rewrite those branches to have non-standard branch paths
>>>> (e.g. refs/tags/old-branches/<whatever>) the history will be preserved
>>>> but hidden.  For example, you won't see these tags when you do a default
>>>> checkout.  Then anyone who wants to "re-activate" the branch can just
>>>> create a new branch on that commit using a standard path, or rename the
>>>> ref.
>>>>
>>>> I think this is probably the right way to go: rewrite all branches but
>>>> develop and master (are there any other branches that deserve special
>>>> status?) into a non-standard path.  If we can determine which tags are
>>>> actual release tags, we might want to rewrite all the others into
>>>> non-standard paths.
>>>
>>> I agree that we should rename the old branches. As a prefix, I suggest
>>> "svn-" instead of "old-" to make it more explicit where those branches
>>> come from.
>>>
>>> I disagree that branches from Subversion should become tags in Git.
>>
>> Judgement call; I could live with it either way.
>
> Lets see how GitHub treats branches and tags:
>
> A tag is something final, something end users want to download, a
> release.

Depends how you look at it.  From my perspective a tag is simply an
unchanging (by convention) marker for a particular commit.  Further
commits may proceed from there, but some branch ref will be tracking
them.

> GitHub creates a download page called "Releases" from the
> tags.  Example: https://github.com/boostorg/atomic/releases We
> certainly don't want to clutter that view with old branches.

Definitely not.  That's why I suggested tags/old-branches/whatever.  I
don't think that will show up in the "releases" area.  When you nest
refs below the default paths, git treats them specially and doesn't push
them at you.  I suspect GitHub does something similar.

> A branch is something intermediate, work in progress, sometimes just
> an experiment. 

Depends how you look at it.  From my perspective a branch is just an
automatically-updating marker for a particular commit.

> A developer may want to keep a branch for future
> reference, or delete it when it is lo longer relevant.

Sure.

> GitHub creates an overview of braches where each branch can be easily
> compared with the main development branch. It also provides an easy
> way to get rid of old branches.
> Example: https://github.com/boostorg/atomic/branches

Sure.

>>> I whould even turn non-release-tags from Subversion into branches.
>>
>> Why?
>
> Because the non-release-tags are actually branches, ie. work in
> progress or experiments (see above).

The thing that distinguishes tags from branches is whether they are
expected to change.  I wanted to keep these things in
tags/old-branches/whatever because presumably there they'd be out of the
way until and unless someone wanted to use them as the base for further
development.  At that point they could create a branch named "whatever"
from that commit and continue.

> About six years ago, some release tags were renamed from
> release/Version_X_XX_X to release/Boost_X_XX_X. Renaming in svn is
> performed by remove and add. So, a tag was removed and a tag was
> added. Boost2Git does not delete old branches/tags. Hence, we ended up
> with two tags: release/Version_X_XX_X and release/Boost_X_XX_X. 

Didn't we just direct both those tags at a single Git ref?  If not, why not?

> But actually, only the latter is the end result, while the former is
> the work in progress, the *branch* that led to the tag.

OK

>>> Here is what I would do (and I can do that, if everybody agrees).
>>>
>>> * Prefix all branches from Subversion with "svn-branches" (master and
>>> develop excluded) .
>>> * Turn non-release-tags from Subversion into branches and prefix them
>>> with "svn-tags".
>>> * Rename release tags from "release/Boost_X_XX_X" to "boostX.XX.X".
>
> GitHub suggests to use the pattern vX.Y.Z. Since some Boost libraries
> already use their own version numbers (eg. Asio and Spirit),
> by using "boost" as a prefix we express the following: This is not
> version X.Y.Z of the library, but the version that went into Boost
> version X.YY.Z.
>
>>> * Remove all "svn-branches" and "svn-tags" from the superproject.
>>
>> Why?
>
> To make sure the superproject does not reference deleted branches. See below.
>
>>> * Allow library maintainers to drop/rename their "svn-branches" and "svn-tags".
>>
>> OK.

We wouldn't have a problem of unreferenced commits if we hid the refs
instead of deleting them.

-Dave