on Tue Feb 28 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Wed Feb 08 2012, Daniel James <dnljms-AT-gmail.com> wrote:
The problem that we face with something like gitflow is testing. We only have the infrastructure for testing two branches so we can't adequately test feature branches. We really do need to test on a wide variety of platforms as early as possible.
The way we plan to handle this with Ryppl is that you check in a testing specification with your project. The testing specification is just a text file, something like this JSON:
{ <configname>: { dependencies: { /* dependency versions */ <libname>: <git tree-ish>, ... }, cmake: { /* properties passed to cmake */ <key>: <value>, ... }, platforms: [ <platform-string>, ... ] }, ... }
Where you can request multiple configurations to be tested for commits on each branch. To get your in-development work tested, just publish a feature branch containing a test specification file to your public repository.
The test results are then added to the commit using git notes.
How convenient will that be for the testers?
If by testers you mean the people that manage machines used as testing resources, it will not require any manual intervention on their part. We may eventually need a way for them to specify which tests they are willing to run, though. For example, I may want my test slave to "opt out" out of all tests of feature branches.
How does this approach compare to the one discussed in http://lists.boost.org/Archives/boost/2012/02/190418.php ?
The message above seems to be (mostly) describing a mechanism for automatically merging feature branches. As far as I can tell, the approaches are apples and oranges, and thus are basically compatible. We do something like that at Boostpro for handling upstream merges to Clang. Once Boost is properly modularized, I'm not sure how important such a mechanism will be for most libraries, which are maintained by individuals. That said, *if* you have to manage lots of long-lived feature branches, a tool like topgit can be used very effectively along with git-flow. There's one important thing about the git-flow model that I'm not sure you've accounted for, though: on feature branches, completely broken commits are de-rigeur.
I take for granted that we're going to have a modularized boost with a separate repository for each library (<https://github.com/boost-lib>) and each library will have its own develop branch.
This sounds like a situation that calls for git-subtree, but maybe I understood git-subtree wrongly.
git-subtree, IIUC, is a mechanism for merging/extracting individual repository histories into/from separate subdirectories of a larger repository. My main question is, why does Boost want to do that? I understand why we want separate repositories, but I don't yet understand why anyone wants a monolithic whole. On the other hand, I *can* see how it would be very useful as a basis for the one-time history-preserving modularization step. -- Dave Abrahams BoostPro Computing http://www.boostpro.com