on Thu Mar 01 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 1 March 2012 00:44, Dave Abrahams <dave@boostpro.com> wrote:
on Wed Feb 29 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 28 February 2012 20:03, Dave Abrahams <dave@boostpro.com> wrote:
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:
Ryppl comes with a few problems.
Specifically?
You should be telling us that. It's vapourware, it's conceptually unproven, it's coupled to a controversial build system, it's a large disruptive change.
Yes, all of these things are true. I'm not sure why I should be telling you that, though. I only asked because I wanted to know to what you were referring.
If the aim is to use git, then it's an expensive precondition.
What is?
If you mean Ryppl... Ryppl is not a precondition for the transition to Git. In some sense it's the other way around: a modularized Boost is a precondition for Boost's transition to Ryppl.
OK then, a modularised boost is an expensive precondition for moving to git.
It isn't a precondition for moving to Git. We can move to Git and then do the modularization step; it's not a problem. However, it does mean two transitions.
Perhaps we should be discussing how to use an alternative version control system while changing as little as possible. The other stuff can come later.
Sure, by all means. I think you misunderstood my posting for some sort of advocacy. We've done some thinking about these problems and I thought the conversation could benefit from that thinking; that's all. -- Dave Abrahams BoostPro Computing http://www.boostpro.com