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). HTH, -Julian