Richard Webb wrote:

Andrey Semashev-2 wrote:

...

Hi,

I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows:

bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage

Does anyone else have these problems?

Same here using VC9 with its own std lib.

Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile.

Confirmed. The fix is trivial: change line 53 from typedef BOOST_DEDUCED_TYPENAME this_t::value_type value_type; to typedef BOOST_DEDUCED_TYPENAME super_t::value_type value_type; Beman, Robert, can we apply this fix before the 1.41 release is out?

I made HUGE blunder. I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back. I'm really, really sorry. Robert Ramey Beman Dawes wrote:

On Sun, Nov 15, 2009 at 7:58 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

...

Richard Webb wrote:

...

Same here using VC9 with its own std lib.

Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile.

Confirmed. The fix is trivial: change line 53 from

typedef BOOST_DEDUCED_TYPENAME this_t::value_type value_type;

to

typedef BOOST_DEDUCED_TYPENAME super_t::value_type value_type;

Beman, Robert, can we apply this fix before the 1.41 release is out?

Seems to me we should fix this. Robert?

--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors. Robert Ramey Beman Dawes wrote:

On Sun, Nov 15, 2009 at 11:23 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

I made HUGE blunder.

I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back.

I'm really, really sorry.

No sweat. I messed up, too - I should have detected that some of the release tests were stale and waited until they cycled. I see that the changes have been reverted, so will generate release candidates again tomorrow once the fresh tests cycle.

The critical point, however, is that we did follow the procedure of asking for independent verification that the release candidate builds OK.

Many thanks to Andrey for detecting the problem, and Richard for confirming it!

--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi, On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:

As an experiment, I've locked branches/release while I build a new release candidate.

One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?

I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally. Regards, Eugene

On Mon, Nov 16, 2009 at 9:41 AM, troy d. straszheim <troy@resophonic.com> wrote:

Eugene Wee wrote:

...

Hi,

On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:

...

As an experiment, I've locked branches/release while I build a new release candidate.

One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?

I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally.

You're right, there is no such operation, the distributed architecture makes it unnecessary.

The point isn't always just for the release manager to be oblivious to further changes, it may also be to prevent those further changes to the master server (or whatever Git calls it) in the first place. I probably don't understand how the master server is updated and administered in a distributed environment. That will probably become obvious if I do some more reading. Thanks, --Beman

Beman Dawes wrote:

On Sun, Nov 15, 2009 at 8:11 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors.

As an experiment, I've locked branches/release while I build a new release candidate.

One problem: It took just one minute shy of two hours to apply the lock. That's no fun.

Wow. Presumably lock of entire branch is not the primary use case for 'svn lock'. You can actually do: svn cp ^/branches/release ^/branches/1_41_0_final svn sw ^/branches/1_41_0_final as the first step in release preparation. That's likely to be much faster. (The ^ syntax works only if you're in a working copy).

Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?

Well, given that git does not have locks, it's a trick question. You can write a hook to disable commits to a specific branch, and install that hook in no time -- but you can do the same in subversion (or use path-based authorization). In both cases, you need direct access to server. - Volodya

On 11/16/2009 09:48 AM, Beman Dawes wrote:

Interesting. But it is a bit more complex than that due to the need to do separate Unix line ending and Windows line ending exports. I'll explore further.

Can the line-ending adjustment not be done as part of the packaging process ? I would expect there are other advantages for building releases / packages out of the very same source tree... Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Mon, Nov 16, 2009 at 12:45 AM, Robert Ramey <ramey@rrsd.com> wrote:

OK - I've reverted the changes from the release branch and commited them to the trunk as I originally intended.  At least I think I did as SVN is a little unwieldy for this operation and always leaves me wondering if I got it right.

The tests seem to have cleared, so that's a good sign. A refreshed release candidate should be available later today. Thanks, --Beman