|
Boost : |
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-09-26 21:13:16
Michael Marcin wrote:
> Hello,
>
> I work with Boost on a daily basis and generally I work with svn trunk.
> I also use some boostified libraries that are not officially accepted
> into Boost yet. There are also times when I need to make changes to the
> way a component or library behaves that are not well factored enough to
> make it in to the official tree but serve their purpose.
>
> How do I manage these complications?
>
> At present I have a folder named boost which has an external named clean
> to svn trunk and a folder named patch which mirror's trunk's layout but
> contains some unofficial boost components from the vault or the sandbox
> as well as some local modifications but not a full copy of trunk.
>
> The first problem comes up while extending BBv2 to handle a new
> compiler. I must point boost-build.jam to a directory and it will look
> there for all its files so if I have changes I have to copy the entire
> boost/tools/build folder into the patch directory tree. Now I'm free to
> modify it and add files but it will quickly go stale and need to be
> resynced with trunk.
>
> I thought of creating svn patch files, checking those into my local
> repository and then just applying those patches when I checkout but
> those cannot handle the addition of files. It also makes it impossible
> to simply checkout from svn and have things just work which I very much
> want.
>
> I have a similar problem with the open source Adobe libraries which
> relates back to Boost. I need to patch those libraries to point to my
> version of Boost not theirs so I don't have 2 versions of Boost floating
> around in my code.
>
> In the past I've just copied the whole repository done my changes
> locally and hand merged with the latest from the Boost repository when I
> needed to update. This is tedious and error prone.
>
> Does anyone else have this problem?
> If so, how did you solve it?
>
>
I'm using mercurial (hg) and mercurial queues (mq).
I have a dir boost.svn that is a checkout of boost svn. It is also under an
hg repository. Then I have my own working copy under boost.hg.
Whenever I like, I goto boost.svn and do
svn update
hg addremove << performs any add/deletes that svn did
hg ci -m 'update' << commit the changes
Then goto boost.hg and do:
hg qpop -a << pop off my local patches
hg pull -u ../boost.svn << pull updates in
hg qpush -a << push back my local patches
If you want to preserve all of svn history, you can use the hg convert
extension to convert svn to hg. This seems far more than my simple needs
require.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk