On Fri, Jan 7, 2011 at 8:53 AM, Nat Linden
<nat@lindenlab.com> wrote:
On Thu, Jan 6, 2011 at 5:22 PM, Geoffrey Romer
<gromer@google.com> wrote:
I'm responsible for maintaining the local Boost install for a large group of developers, and 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.
I do understand the problem. 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. We've used that tactic fairly successfully ourselves.
When a local patch is applied upstream and eventually arrives in your local repository, either the merge is trivial (because your local code is now identical to the vendor code) or you get a merge conflict, which you can resolve in favor of the new vendor code.
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.
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). 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.
In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
But it's all volunteer effort. I'm impressed that Marshall responded as he did to your request.
I know it's a volunteer effort; that's why I've tried to do everything I can to minimize the workload on those volunteers, by providing detailed reports, patches, etc. Part of my frustration is that our voluntary efforts to give back to Boost were getting dropped on the floor, along with who knows how many others'. If I could check the fixes in myself, I would; I know it's not feasible to provide commit access to all and sundry, but the policy of granting commit access only to owners of particular libraries seems like it may be cutting Boost off from a useful pool of volunteers.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users