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

Subject: Re: [boost] [git] [modular boost] Switchover schedule proposal
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-10-29 06:36:57

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

A branch is something intermediate, work in progress, sometimes just
an experiment. A developer may want to keep a branch for future
reference, or delete it when it is lo longer relevant.
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

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

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. But
actually, only the latter is the end result, while the former is the
work in progress, the *branch* that led to the tag.

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

Cheers, Daniel