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-30 04:57:23

2013/10/30 Dave Abrahams <dave_at_[hidden]>:
> 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.

AFAIR, that list was a little longer before I made the change.

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

OK, I see your point.

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

We didn't. But I think we decided to do that. I did that now.

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

I don't suggest deleting any branches in the libraries. I suggest
allowing maintainers to delete branches in their libraries.
Therefore, we must assume some branches will get deleted.

In the superproject, we don't want to reference deleted branches from
the libraries, so we delete all branches that might potenially
reference a deleted branch from a subproject.

If we hide the branches in the superproject instead of deleting them,
they still will be accessible, so we would still have the problem,
don't you think?

If we hide the branches in the subprojects instead of... what? The
only alternative here would be to not allow maintainers to delete old
branches. I don't want to force anybody in this direction.