[git] Some questions on Git transition
* I see we have a GitHub account at https://github.com/boostorg, with repositories for each library. If we add a new library, and it has been Git-based, are we going to mirror it in the Boost account? That'll make sure if something happens to the original, we still have a last-known-good to work with. Would having all the libraries (or copies/mirrors) under the same account make scripts easier? What about non-Git libraries, will they be copied over? Would a bridge be used? (There's at least bridges for Git connecting to either Subversion or Mercurial.) * We currently ship all the libraries merged together as a single archive. Some package managers even provide the Boost libraries as a single item. When we go Git, is that still going to be in place (with the release managers doing some sort of merging script), or are we and every user going to move to doing several dozen downloads instead? (And everyone has to figure out how to use more than one Boost library at once.) * Are we eventually going to use something like http://nvie.com/posts/a-successful-git-branching-model/? If so, are we going to use that to script releases? (At release-time, grab the latest version of each library from their master branches, apply the merging script, run tests, then ship.) Daryle W.
on Wed Aug 21 2013, Daryle Walker
* I see we have a GitHub account at https://github.com/boostorg, with repositories for each library.
Yes, those repositories are being generated dynamically from SVN by https://github.com/ryppl/Boost2Git#boost2git
If we add a new library, and it has been Git-based, are we going to mirror it in the Boost account?
Well, we'll have a repo for it under github.com/boostorg/, which will be where the official Boost releases are made from.
That'll make sure if something happens to the original, we still have a last-known-good to work with. Would having all the libraries (or copies/mirrors) under the same account make scripts easier?
Yes, and we plan to do that.
What about non-Git libraries, will they be copied over?
What's a non-Git library? Serious question.
Would a bridge be used? (There's at least bridges for Git connecting to either Subversion or Mercurial.)
Boost libraries will be officially developed under Git. People can use bridges or other tools to develop if they like, but Git is going to be a requirement for Boost libraries going forward.
* We currently ship all the libraries merged together as a single archive. Some package managers even provide the Boost libraries as a single item. When we go Git, is that still going to be in place (with the release managers doing some sort of merging script), or are we and every user going to move to doing several dozen downloads instead? (And everyone has to figure out how to use more than one Boost library at once.)
There are two answers to this, no and no. :-) The first "no" is that we are also producing https://github.com/boostorg/boost, which is a monolithic snapshot of everything that refers to the other repositories as submodules. All of Boost's SVN history is captured there, and after the transition each whole-Boost release and release candidate will be available in that repository as a tag. The second "no" is that Ryppl is intended to be a tool that manages inter-library dependencies and resolves them for you as needed, so that you don't have to grab all of Boost just to do a bit of development. But Ryppl is a long-term goal, not a short-term reality.
* Are we eventually going to use something like http://nvie.com/posts/a-successful-git-branching-model/?
We have already agreed to use exactly that model (git-flow).
If so, are we going to use that to script releases? (At release-time, grab the latest version of each library from their master branches, apply the merging script, run tests, then ship.)
What merging script? :-) The plan for monolithic Boost releases is to continuously test a revision of http://github.com/boostorg/boost whose submodule references point only to release tags in each sub-repository. When the release managers like those test results, they can ship the release. -- Dave Abrahams
From: dave@boostpro.com Date: Sat, 24 Aug 2013 13:01:36 -0700
on Wed Aug 21 2013, Daryle Walker
wrote: If we add a new library, and it has been Git-based, are we going to mirror it in the Boost account?
Well, we'll have a repo for it under github.com/boostorg/, which will be where the official Boost releases are made from.
That'll make sure if something happens to the original, we still have a last-known-good to work with. Would having all the libraries (or copies/mirrors) under the same account make scripts easier?
Yes, and we plan to do that.
What about non-Git libraries, will they be copied over?
What's a non-Git library? Serious question.
Would a bridge be used? (There's at least bridges for Git connecting to either Subversion or Mercurial.)
Boost libraries will be officially developed under Git. People can use bridges or other tools to develop if they like, but Git is going to be a requirement for Boost libraries going forward. For these questions, I'm talking about a prototype Boost library, kept on a Git repository, a non-Git repository (e.g. Subversion or Mercurial), or winging it on the authors' hard drives. But the first version of a new approved library will be copied over to our GitHub site as a new module without transferring any history (if it was from Git or another SCM)? Daryle W.
on Sat Aug 24 2013, Daryle Walker
From: dave@boostpro.com
Boost libraries will be officially developed under Git. People can use bridges or other tools to develop if they like, but Git is going to be a requirement for Boost libraries going forward.
For these questions, I'm talking about a prototype Boost library, kept on a Git repository, a non-Git repository (e.g. Subversion or Mercurial), or winging it on the authors' hard drives. But the first version of a new approved library will be copied over to our GitHub site as a new module without transferring any history (if it was from Git or another SCM)? Daryle W.
The author is free to transfer as much or as little history as he likes. Also, we plan to conduct reviews against a known revision of a GitHub repository, so there will be continuity between the reviewed library and the one that ends up "in Boost." -- Dave Abrahams
participants (2)
-
Daryle Walker -
Dave Abrahams