[1.40.0] Unmerged changes delaying beta 1

There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release. "svn diff" can be used to see exactly what changes have not been merged. Here is a simple Windows batch file that eases typing; perhaps someone could post a Unix equivalent. @echo off if not %1$==$ goto usage_ok echo Usage: unmerged library-name goto done :usage_ok svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1.hpp http://svn.boost.org/svn/boost/trunk/boost/%1.hpp svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1 http://svn.boost.org/svn/boost/trunk/boost/%1 svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/libs/%1 http://svn.boost.org/svn/boost/trunk/libs/%1 :done If your library has changes that need to be merged, please do so right away. I'll hold off on the beta until Monday morning to give folks a chance to do merges and let tests cycle. --Beman accumulators algorithm any array asio assign bimap bind circular_buffer compatibility concept concept_check config conversion crc date_time detail disjoint_sets dynamic_bitset exception flyweight foreach format function function_types functional fusion gil graph integer io iostreams iterator lambda math mpi mpl multi_array multi_index numeric optional parameter pool preprocessor program_options property_map proto ptr_container python random range rational regex scope_exit serialization signals smart_ptr spirit statechart static_assert system thread timer tokenizer tr tuple type_traits typeof units unordered utility variant wave xpressive

There seem to be a large number of changes to trunk that have not been merged into branches/release. [snip]
Regarding Statechart, I see the following differences between trunk & release: libs/statechart/CMakeLists.txt libs/statechart/doc/index.html libs/statechart/example/CMakeLists.txt libs/statechart/module.cmake libs/statechart/test/CMakeLists.txt The index.html difference is intended, all others don't seem to be real. TortoiseSVN shows them as "replaced", but the trunk & release versions are identical. Maybe you are getting such a long list of unmerged changes because the cmake files for other libraries were also replaced? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

Beman Dawes wrote:
There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release.
I checked my libs, and most of the diffs are related to changes to the CMake build system. I don't know whether the diffs are intentional or not. -- Eric Niebler BoostPro Computing http://www.boostpro.com

config
I haven't changed anything (I don't think) so it's more likely to be your C++0x stuff?
math
Spurious doc changes (auto-generated ID's are different).
regex
CMake changes, I know nothing about those.
static_assert
Typo in example. Will merge.
tr
Deliberate changes, should not be merged yet.
type_traits
Deliberate changes, should not be merged yet. John.

Beman Dawes wrote:
"svn diff" can be used to see exactly what changes have not been merged. Here is a simple Windows batch file that eases typing; perhaps someone could post a Unix equivalent.
@echo off if not %1$==$ goto usage_ok echo Usage: unmerged library-name goto done
:usage_ok svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1.hpp http://svn.boost.org/svn/boost/trunk/boost/%1.hpp svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1 http://svn.boost.org/svn/boost/trunk/boost/%1 svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/libs/%1 http://svn.boost.org/svn/boost/trunk/libs/%1
:done
Here's the equivalent for bash: #!/bin/bash if [ $# -eq 1 ]; then library="$1"; shift for tail in boost/$library.hpp boost/$library libs/$library; do svn diff "${@}" http://svn.boost.org/svn/boost/{branches/release,trunk}/$tail done else echo >&2 Usage: $0 library-name exit 1 fi _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Beman Dawes skrev:
There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release.
assign ptr_container
please continue the release without merging these two. -Thorsten

Beman Dawes wrote:
There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release.
"svn diff" can be used to see exactly what changes have not been merged. Here is a simple Windows batch file that eases typing; perhaps someone could post a Unix equivalent.
program_options
I believe the script is confused here. There are no actual code changes, just mergeinfo changes -- which are expected and will always be there. See below for svn diff output. - Volodya ghost@wind:~/Work/Boost/boost-svn$ svn diff ^/branches/release/boost/program_options ^/trunk/boost/program_options Property changes on: . ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /trunk/boost/boost/program_options:r22824-38326 Reverse-merged /devel/boost/program_options:r38327-38328 Reverse-merged /trunk/boost/program_options:r38329-55194,55224 ghost@wind:~/Work/Boost/boost-svn$ svn diff ^/branches/release/libs/program_options ^/trunk/libs/program_options Property changes on: . ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /trunk/boost/libs/program_options:r22824-38326 Reverse-merged /devel/libs/program_options:r38327-38328 Reverse-merged /trunk/libs/program_options:r38329-55193,55224

Matthias Troyer wrote:
On Aug 8, 2009, at 10:44 AM, Beman Dawes wrote:
mpi
That should be fixed now.
serialization
AFAIK the trunk already contains changes made for 1.41 that we do not want to move to the release branch yet.
This is correct. The only change I need to do is merge in changes in the release documentation - one file. Robert Ramey
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Sorry, the release branch is badly out of date for Boost.Python. I've only maintained the trunk for a long time. A few days ago someone suggested re-branching after the 1.40 release. How likely is this to happen? Ralf ----- Original Message ---- From: Beman Dawes <bdawes@acm.org> To: Boost Developers List <boost@lists.boost.org> Sent: Saturday, August 8, 2009 9:44:00 AM Subject: [boost] [1.40.0] Unmerged changes delaying beta 1 There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release.

On Mon, Aug 10, 2009 at 7:58 PM, Ralf W. Grosse-Kunstleve<rwgk@yahoo.com> wrote:
Sorry, the release branch is badly out of date for Boost.Python. I've only maintained the trunk for a long time.
Isn't this a showstopper? Is there any reason not to merge into branches/release right away? There are, however, two tests (exec and exec-dynamic) that are failing on trunk for all platforms. Do these need fixes?
A few days ago someone suggested re-branching after the 1.40 release. How likely is this to happen?
I must have missed that thread. Which one was it? We never re-branch the trunk. If a library has changes in trunk that should go in the next release, those changes need to be merged into branches/release. --Beman

On Mon, Aug 10, 2009 at 7:58 PM, Ralf W. Grosse-Kunstleve<rwgk@yahoo.com> wrote:
Sorry, the release branch is badly out of date for Boost.Python. I've only maintained the trunk for a long time.
Isn't this a showstopper? Is there any reason not to merge into branches/release right away?
I could try to merge everything now. I was assuming it is too late and that it is better to hold off until after the 1.40.0 release. (I don't have any experience working with the release branch...)
There are, however, two tests (exec and exec-dynamic) that are failing on trunk for all platforms. Do these need fixes?
A few days ago someone suggested re-branching after the 1.40 release. How likely is this to happen?
I must have missed that thread. Which one was it?
http://lists.boost.org/Archives/boost/2009/07/154373.php Ralf

f.y.i, Theres a difference in Signals due to the fix for #2023 (made to Trunk ~14 months ago) never having made it to the release branch. -- View this message in context: http://www.nabble.com/-1.40.0--Unmerged-changes-delaying-beta-1-tp24879861p2... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Thu, Aug 13, 2009 at 7:20 AM, Richard Webb<richard.webb@boldonjames.com> wrote:
f.y.i, Theres a difference in Signals due to the fix for #2023 (made to Trunk ~14 months ago) never having made it to the release branch. --
Hum... Looks that way to me too. I've pinged Doug. Thanks, --Beman

Beman Dawes <bdawes <at> acm.org> writes:
There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release. [...]
flyweight [...] multi_index [...]
Hi Beman, sorry for the late response, been offline during the last week, and will go offline again in a day or so. Differences in flyweight and multi_index are concentrated in CMake-specific files, whose maintenance I'm not responsible for. Also, some of the differences, in my libs as well as many others, are related to the issue commented in this post: http://lists.boost.org/boost-cmake/2009/06/0592.php which unfortunately went unanswered. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

On Sat, Aug 15, 2009 at 1:17 PM, Joaquin M Lopez Munoz<joaquin@tid.es> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release. [...]
flyweight [...] multi_index [...]
Hi Beman, sorry for the late response, been offline during the last week, and will go offline again in a day or so. Differences in flyweight and multi_index are concentrated in CMake-specific files, whose maintenance I'm not responsible for.
Also, some of the differences, in my libs as well as many others, are related to the issue commented in this post:
http://lists.boost.org/boost-cmake/2009/06/0592.php
which unfortunately went unanswered.
While we can do the 1.40.0 release without resolving the CMake-specific issues, we need to get them straightened out moving forward. Thanks, --Beman
participants (13)
-
Andreas Huber
-
Beman Dawes
-
Eric Niebler
-
Hartmut Kaiser
-
Joaquin M Lopez Munoz
-
John Maddock
-
Matthias Troyer
-
Ralf W. Grosse-Kunstleve
-
Richard Webb
-
Robert Ramey
-
Stewart, Robert
-
Thorsten Ottosen
-
Vladimir Prus