|
Boost : |
Subject: Re: [boost] ryppl and cmake
From: joel falcou (joel.falcou_at_[hidden])
Date: 2010-05-24 14:41:50
David Abrahams wrote:
> 0. Cross-posting to the ryppl-dev list
>
Lemme register then ;)
> 1. Yes, in principle it can support those other VCSes. In fact,
> there's infrastructure in PIP that allows the specifics of the VCS
> to be abstracted away.
>
OK
> 2. My priority is on smoothness of operation. I want all the
> workflows described at http://ryppl.org/workflows.html to be as
> painless as possible, and I'm perfectly happy to mandate the use of
> Git for ryppl if it is going to make the difference between âjust
> worksâ and âhassle.â If you really want to use Mercurial for your
> own development you can always leverage hg-git
> (http://hg-git.github.com), and I'm sure there's something similar
> for bzr.
>
It's fine by me. Fact is that I don't *want* to use Mercurial but my
surroundings are (university, lab etc) so
I'm trying to minimize the problem if I want them to adopt ryppl
globally (that's my goal).
As for hg-git, i didn't knwo about it, thanks for the link.
> 3. At the risk of alienating some people⦠I believe Git is going to
> win the DVCS wars. It has the momentum. And as truly obnoxious as
> Linus' remarks about other VCSes have been, I have been working
> with them too recently, and I am forced to agree with him. So I'm
> personally not interested in investing much effort in other VCSes.
>
Let's see. I'm rather agnostic on this side. Whatever do the work
properly for me
is good.
> 4. However, if someone comes along who wants to do the work, and can
> make me confident that s/he'll maintain it, and can make me
> confident that the system won't have to sacrifice usability, well
> then I have no objections :^)
>
It may be this guy we'll end up hiring for our own concern that will
have to work wiht ryppl anyway.
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk