Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-10 11:35:13
Paul A. Bristow wrote:
>> Julian Gonggrijp wrote:
>>> A side-by-side visual comparison would probably be a good idea. I'm
>>> working on such a picture, I hope to send it tomorrow.
>> As promised:
>> http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
> Thanks for all of this - I am beginning to understand how git might help us.
> Can I also raise the potential (re-)position of boost-sandbox?
> At present, some links in jamfiles, and especially many in docs, need tiresome readjustment
> to be able to move from sandbox to trunk.
> Would it be possible to avoid this by making sandbox a branch from trunk.
> Most of the items of course never make it into trunk, and are abandoned,
> but if they do get accepted, then moving will be painless.
> Could using git help us here?
Yes, git can certainly help here, because of its decentralized nature.
If I'm right the sandbox is mostly used for new libraries that authors
intend to add to the main distribution at some point of time. With
git, those authors can just clone the central boost repository and add
their library to the clone (in a feature branch). They can also
publish their clone in order to collaborate. When the additions in the
clone are ready to be pushed/pulled into the central boost repository,
you can just do that and no file paths will need to be changed. After
that you can merge the new feature branch into develop.
The merge shouldn't require any manual intervention either, as long as
the collaborators on the clone didn't touch any other parts of the
boost tree along the way.
For those cases where the sandbox is used for additions to existing
libraries, or where the author already has write access to the central
repository, the sandbox can simply be omitted by using feature
branches instead -- without any need to clone the central repository.
If this needs a picture as well, I'll be happy to make it (tomorrow).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk