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

Daniel Pfeifer writes:

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.

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