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

2013/10/29 Dave Abrahams :

Daniel Pfeifer writes:

...

2013/10/28 Dave Abrahams :

...

Daniel Pfeifer writes:

...

2013/10/27 Dave Abrahams :

...

Antony Polukhin 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