Boost logo

Boost Users :

Subject: Re: [Boost-users] How to get bug reports addressed
From: Nat Linden (nat_at_[hidden])
Date: 2011-01-07 14:49:34


On Fri, Jan 7, 2011 at 1:03 PM, Geoffrey Romer <gromer_at_[hidden]> wrote:

>
>
> On Fri, Jan 7, 2011 at 8:53 AM, Nat Linden <nat_at_[hidden]> wrote:
>
>> On Thu, Jan 6, 2011 at 5:22 PM, Geoffrey Romer <gromer_at_[hidden]> wrote:
>>
>> I find myself spending an inordinate amount of time reapplying our local
>>> patches for Boost bugs every time a new version comes out, seemingly with no
>>> end in sight.
>>
>>
>> It seems to me that this is exactly what Vendor Branches:
>> http://svnbook.red-bean.com/en/1.1/ch07s05.html
>> is intended to address.
>>
>
> Yeah, that's a good idea. Unfortunately, our local source control is not
> Subversion, and maintaining a local svn repository just for occasional Boost
> upgrades seems like overkill. There may be some way to get our source
> control to interoperate with svn in a way that will make this work, but if
> so, I haven't found it.
>

? The technique doesn't seem to be specific to Subversion; it's about
getting your revision-control system to merge, into your (locally-modified)
trunk, the delta needed to update from the previous Boost version to the
newer Boost version. Mercurial even has 'hg addremove', which looks to me
like an improvement over svn_load_dirs.pl.

One reasonable approximation to this approach would be if I could generate a
> patch file that takes one release version of Boost to the next; I could then
> apply that patch to perform the upgrade, and my local modifications would
> remain intact (except in the case of conflicts, which I can merge by hand).
>

Yes, exactly!

> However, I haven't been able to work out how to identify a particular
> release version of Boost in the repository, in order to generate such a
> patch.
>

Hmm, I'm not quite sure what you're saying here.



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net