On Sat, Oct 26, 2013 at 9:39 AM, Daniel James wrote:

On 25 October 2013 13:22, Beman Dawes wrote:

...

That would mean an actual switchover starting about November 11.

It seems to me we need approximately a week after svn is made read-only and the final conversion run is done to verify the correctness of the conversion. During that time it seems to me that it would be unwise for developers to make git commits since if a serious problem was discovered we might decide to rerun the conversion process, wiping out the git repos.

At that point (roughly November 18, we would go totally live and developers could resume their work, now using git and modular boost.

I've added these dates to the calendar. Any thoughts on what I should put for the 1.56 schedule? Is there an equivalent of closing the release branch?

For the individual libraries, the rhythm will different. That should become clearer over then next couple of weeks as we generate more documentation. For the Boost super-project, the mechanics will be different but I think the big picture remains similar. Let's set the release date using the usual formula. Perhaps set the beta release date a week earlier than usual to allow plenty of testing. I'm wondering if a planned alpha release would also be a good thing? Its objective would be to work the kinks out of the release procedure, so it would just contain whatever updates happen to be ready. Cutoff dates would be unnecessary - given Git's easy branching and merging we could do an alpha without bothering developers with closing our main branches. Beta and final releases may end up being similar to the alpha. There would be cutoff dates that have to be met to get changes into the release, but maybe we can eliminate the need to actually close branches. I'd say go ahead and set some dates, with the caveat that they will change as our planning firms up. Thanks, --Beman

2013/10/26 Andrey Semashev <...>

I'd like to ask you (or anyone else working on the transition to git) to post a formal email to this list describing the final workflow with Boost for the developers, when the transition is complete. I know about master and develop branches and that there were scripts to checkout the monolithic Boost. But there are many more questions that need to be answered, like:

- Will there be a lockdown for master branches during the release cycle? - Will there be support branches for particular releases? - What branches will be tested? - What is the procedure for me applying patches to the libraries I don't maintain (e.g. to fix breakage in an other library)? - Will we keep using trac for tickets?

and all other things people need to know to perform the development, like before the transition.

<...> - How to run regression tests using run.py and git? - How to setup b2 for running regression tests for an individual library (currently it is just `cd libs/library_name/test; ../../../b2`) - Can I merge and delete branches in GIT without affecting the whole system stability (for example `conversion` library currently contains branches like `filesystem_V3`) - What about the docs? Will something change or docs still will be generated by web-site maintainers for each release? -- Best regards, Antony Polukhin

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. Cheers, Daniel

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. I whould even turn non-release-tags from Subversion into branches. 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". * Remove all "svn-branches" and "svn-tags" from the superproject. * Allow library maintainers to drop/rename their "svn-branches" and "svn-tags". Cheers, Daniel

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

2013/10/29 Andrey Semashev :

On Tue, Oct 29, 2013 at 2:36 PM, Daniel Pfeifer wrote:

...

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.

Not quite. The added file/directory also has a property that tells where it originated from so that it is possible to track file moves/renames.

Correct, but that does not change the point I am making: We ended up with two tags, where only one is desired.

2013/10/29 Andrey Semashev :

On Tue, Oct 29, 2013 at 4:15 PM, Daniel Pfeifer wrote:

...

2013/10/29 Andrey Semashev :

...

On Tue, Oct 29, 2013 at 2:36 PM, Daniel Pfeifer wrote:

...

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.

Not quite. The added file/directory also has a property that tells where it originated from so that it is possible to track file moves/renames.

Correct, but that does not change the point I am making: We ended up with two tags, where only one is desired.

Doesn't Boost2Git handle moves? I.e. the old-named tags should appear deleted, shouldn't they?

Boost2Git does not delete branches/tags. When you delete a branch in svn, it still exists in the history. But when you delete a branch in git, it is truly gone. So we decided to keep all deleted branches. As a post-processing, we delete all merged branches, ie. the result of `git branch --merged`. Copied tags do not count as merged branches. cheers, Daniel

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

...

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.

The issue I see with having tags at all before the final migration is that 'fetch'ing doesn't update tags, only branches and therefore, anyone that pulls the repo's now will have tags that don't match any changes going forward for any tag that doesn't have a different name. I suppose that should be documented somewhere and how to fix it (they would have to delete their local tags and then fetch again).

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.

This is a complex situation and there probably isn't a good answer. If you have the approach of tags or hidden tags, they slowly become useless as maintainers slowly delete branches that the superproject refers to. However, if you require that devs delete the tag first, there's no stopping someone from pushing it back later, besides the fact that they couldn't get the consensus to remove it (short of the steering committee voting to delete them). And if you don't have the data in the superproject, then you lose changes that depended on multiple libraries. So, exactly what is the goal here? It's not obvious what these changes from branches to tags is to achieve other than 'sweeping them under a rug'? Hopefully that doesn't sound negative, I'd just like to understand the vision if only to ensure that you guys have thought this through. (Though, there is something to be said for just getting it done and over with. :) )

Just wondering if the switchover was starting today as discussed? -- View this message in context: http://boost.2283326.n4.nabble.com/git-modular-boost-Switchover-schedule-pro... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Sun, Oct 27, 2013 at 1:03 PM, Dave Abrahams wrote:

Antony Polukhin writes:

I can answer one of your questions below:

...

- 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. It would be better to rename the branch in question as a nested tag, e.g.

refs/heads/some-old-branch

becomes

refs/tags/old-branches/some-old-branch

then it will hide, but the commit won't disappear.

Beman, it might make sense for us to make those changes as part of the conversion.

Hum... It had not occurred to me that other libraries might be referencing commits on some of my libraries branches. I was planning to blow most of the old branches away. I guess that needs reconsidering, at least for the branches that are truly mine, and not just artifacts of conversion. --Beman

On 27 October 2013 14:48, Antony Polukhin wrote:

- What about the docs? Will something change or docs still will be generated by web-site maintainers for each release?

The documentation should be dealt with in the same way at first. Will probably need to spend a bit of time fixing links (mainly to headers), but I want to keep the initial documentation as close to the current version as possible. Later we might try to deal with the documentation in a modular fashion. I have some ideas about how that could work, but it'll need support from the build tool, so that might take a while. And we shouldn't start until everything else has settled down.

On Sat, Oct 26, 2013 at 3:03 PM, Andrey Semashev wrote:

I'd like to ask you (or anyone else working on the transition to git) to post a formal email to this list describing the final workflow with Boost for the developers, when the transition is complete. I know about master and develop branches and that there were scripts to checkout the monolithic Boost.

I'm trying to put in a couple of hours a day building documentation. You can follow progress starting with the links in the "Git and Modular Boost" section of https://svn.boost.org/trac/boost/wiki

But there are many more questions that need to be answered, like:

- Will there be a lockdown for master branches during the release cycle? - Will there be support branches for particular releases? - What branches will be tested? - What is the procedure for me applying patches to the libraries I don't maintain (e.g. to fix breakage in an other library)? - Will we keep using trac for tickets?

I've added you questions and Dave's answers to the "Modular Boost Frequently Asked Questions" page. See https://svn.boost.org/trac/boost/wiki/ModCvtFAQ --Beman

Le 28/10/13 14:16, Beman Dawes a écrit :

On Sat, Oct 26, 2013 at 3:03 PM, Andrey Semashev wrote:

...

I'd like to ask you (or anyone else working on the transition to git) to post a formal email to this list describing the final workflow with Boost for the developers, when the transition is complete. I know about master and develop branches and that there were scripts to checkout the monolithic Boost.

I'm trying to put in a couple of hours a day building documentation. You can follow progress starting with the links in the "Git and Modular Boost" section of https://svn.boost.org/trac/boost/wiki Thanks Beman. This is very useful for the people that are not yet implied on the conversion to Git. Please could you mark the pages that up to date, so that we can not be misguided information that is tot up to date?

...

But there are many more questions that need to be answered, like:

- Will there be a lockdown for master branches during the release cycle? - Will there be support branches for particular releases? - What branches will be tested? - What is the procedure for me applying patches to the libraries I don't maintain (e.g. to fix breakage in an other library)? - Will we keep using trac for tickets?

I've added you questions and Dave's answers to the "Modular Boost Frequently Asked Questions" page. See https://svn.boost.org/trac/boost/wiki/ModCvtFAQ

Hi, I tried to gain write access to a particular Boost library but the link *open an "admin"* issue https://github.com/boostorg/admin/issues in https://svn.boost.org/trac/boost/wiki/ModAdmin . doesn't works for me. Could someone help me? Vicente

Le 28/10/13 14:16, Beman Dawes a écrit :

On Sat, Oct 26, 2013 at 3:03 PM, Andrey Semashev wrote:

...

I'd like to ask you (or anyone else working on the transition to git) to post a formal email to this list describing the final workflow with Boost for the developers, when the transition is complete. I know about master and develop branches and that there were scripts to checkout the monolithic Boost.

I'm trying to put in a couple of hours a day building documentation. You can follow progress starting with the links in the "Git and Modular Boost" section of https://svn.boost.org/trac/boost/wiki

I have reached to do git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh But when I do ./b2 headers as described here Getting Started with Modular Boost https://svn.boost.org/trac/boost/wiki/TryModBoost#InstallingModularBoost I get ./b2 headers link.jam: No such file or directory Jamroot:145: in modules.load ERROR: rule "link-directory" unknown in module "Jamfile". /Users/viboes/github/modular-boost/tools/build/v2/build/project.jam:311: in load-jamfile /Users/viboes/github/modular-boost/tools/build/v2/build/project.jam:64: in load /Users/viboes/github/modular-boost/tools/build/v2/build/project.jam:145: in project.find /Users/viboes/github/modular-boost/tools/build/v2/build-system.jam:535: in load /Users/viboes/github/modular-boost/tools/build/v2/kernel/modules.jam:289: in import /Users/viboes/github/modular-boost/tools/build/v2/kernel/bootstrap.jam:139: in boost-build /Users/viboes/github/modular-boost/boost-build.jam:17: in module scope Am I doing something wrong? Best, Vicente