Robert, I would really appreciate it if you could answer this posting. Thanks. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I've resolved to move these headers from their current locations into the boost/serialization directory. Right now I'm sort of bogged down in other stuff and I've make fairly extensive changes/enhancements to the library. I'm working on a branch. About a month ago I inquired as to the convenience/inconvenience of merging my changes from the branch into the trunk and the response was that as things were soon to be released, it would not be a good time to do so. This was fine with me. So by now my branch is even more divirgent from the trunk. I'll make these changes on this branch which can be merged into trunk at such time as is deemed convenient. Robert Ramey David Abrahams wrote:
Robert, I would really appreciate it if you could answer this posting. Thanks.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I've resolved to move these headers from their current locations into the boost/serialization directory. Right now I'm sort of bogged down in other stuff and I've make fairly extensive changes/enhancements to the library. I'm working on a branch. About a month ago I inquired as to the convenience/inconvenience of merging my changes from the branch into the trunk and the response was that as things were soon to be released, it would not be a good time to do so. This was fine with me. So by now my branch is even more divirgent from the trunk. I'll make these changes on this branch which can be merged into trunk at such time as is deemed convenient.
Understood. However, don't forget that you can always make changes to the trunk as well as the branch, and then merge them later :-) And... without wishing to point fingers... Serialization currently accounds for about half of the outstanding regressions at http://boost.org/regression/trunk/developer/issues.html, so I guess we need to make some sort of decision whether 1.35 will contain: 1) The Boost-1.34 version of serialization (in which case we should revert the Trunk for the time being). 2) Current Trunk version (plus fixes? Looks like many of the failures have a single cause?) 3) The current development branch version that you're actively working on. Which we go for much depends upon Beman's schedule, so over to the release manager I guess ;-) Regards, John.
John Maddock wrote:
Robert Ramey wrote:
I've resolved to move these headers from their current locations into the boost/serialization directory. Right now I'm sort of bogged down in other stuff and I've make fairly extensive changes/enhancements to the library. I'm working on a branch. About a month ago I inquired as to the convenience/inconvenience of merging my changes from the branch into the trunk and the response was that as things were soon to be released, it would not be a good time to do so. This was fine with me. So by now my branch is even more divirgent from the trunk. I'll make these changes on this branch which can be merged into trunk at such time as is deemed convenient.
Understood.
However, don't forget that you can always make changes to the trunk as well as the branch, and then merge them later :-)
I think that would increase the work I have to do.
And... without wishing to point fingers... Serialization currently accounds for about half of the outstanding regressions at http://boost.org/regression/trunk/developer/issues.html, so I guess we need to make some sort of decision whether 1.35 will contain:
1) The Boost-1.34 version of serialization (in which case we should revert the Trunk for the time being). 2) Current Trunk version (plus fixes? Looks like many of the failures have a single cause?) 3) The current development branch version that you're actively working on.
When I look at the trunk results I see the following: a) failure due to the fact that wide character serialization won't build for certain platforms. On the branch, I tweaked to test/Jamfile to make some tests depended on test results on in test/config. So that tests which don't make sense aren't run. This works on my system but I have no idea whether its kosher. In Jamfiles for V1, this was addressed but that code was broken when things moved to V2. I don't know if this combination was tested with 1.34 so I don't know if reverting would help here. b) tests of portable_binary_demo fail on high endien platforms. This demo illustrates how to add functionality to an archive via derivation. However, changes to binary_archive at a basic level break this idea for binary archives. This this demo is broken and in no longer serves its original purpose. I haven't had time to replace it. I believe that the above accounts for all the known failures. c)I've noticed that bjam doesn't detect failure of test_exported which is an imported test. I've got it passing on my branch but I don't know what the true status is on the trunk. d)Changes in implemenation of binary_archives prevent the library from building on older platforms. This doesn't show up in the boost test matrix. Robert Ramey
Which we go for much depends upon Beman's schedule, so over to the release manager I guess ;-)
Regards, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
When I look at the trunk results I see the following:
a) failure due to the fact that wide character serialization won't build for certain platforms. On the branch, I tweaked to test/Jamfile to make some tests depended on test results on in test/config. So that tests which don't make sense aren't run. This works on my system but I have no idea whether its kosher. In Jamfiles for V1, this was addressed but that code was broken when things moved to V2. I don't know if this combination was tested with 1.34 so I don't know if reverting would help here.
Ah, I think the errors in the log reports are misleading, when building with Minw I see: gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-mw\debug\boost_s erialization-mgw-d-1_35.lib ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-m w\debug\boost_serialization-mgw-d-1_35.dll Creating library file: ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-mw\deb ug\boost_serialization-mgw-d-1_35.lib ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-mw\debug\codecvt_null.o: In f unction `ZNSt23__codecvt_abstract_baseIwciED1Ev':C:/MinGW/bin/../lib/gcc/mingw32 /3.4.2/../../../../include/c++/3.4.2/bits/codecvt.h:(.rdata$_ZTVN5boost7archive1 2codecvt_nullIwEE[vtable for boost::archive::codecvt_null<wchar_t>]+0x14): undef ined reference to `std::codecvt<wchar_t, char, int>::do_unshift(int&, char*, cha r*, char*&) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVN5boost7archive12codecvt_nullIwEE[vtable for boost::archive::cod ecvt_null<wchar_t>]+0x20): undefined reference to `std::codecvt<wchar_t, char, i nt>::do_always_noconv() const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVN5boost7archive12codecvt_nullIwEE[vtable for boost::archive::cod ecvt_null<wchar_t>]+0x24): undefined reference to `std::codecvt<wchar_t, char, i nt>::do_length(int&, char const*, char const*, unsigned int) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x1 0): undefined reference to `std::codecvt<wchar_t, char, int>::do_out(int&, wchar _t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x1 4): undefined reference to `std::codecvt<wchar_t, char, int>::do_unshift(int&, c har*, char*, char*&) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x1 8): undefined reference to `std::codecvt<wchar_t, char, int>::do_in(int&, char c onst*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x1 c): undefined reference to `std::codecvt<wchar_t, char, int>::do_encoding() cons t' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x2 0): undefined reference to `std::codecvt<wchar_t, char, int>::do_always_noconv() const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x2 4): undefined reference to `std::codecvt<wchar_t, char, int>::do_length(int&, ch ar const*, char const*, unsigned int) const' :C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/codecv t.h:(.rdata$_ZTVSt7codecvtIwciE[vtable for std::codecvt<wchar_t, char, int>]+0x2 8): undefined reference to `std::codecvt<wchar_t, char, int>::do_max_length() co nst' collect2: ld returned 1 exit status So this is a linker error in building the *narrow character* serialization library: there are several tests in Date-time and elsewhere that are then also failing because of this. This may be caused by the change to BBv2 though: as dynamic rather than static linking is now the default. The easy hack I guess would be to enforce static linking only of Boost.Serialization on MingW32 (as the tests do build with link=static), but it would be better to #ifdef the code so as not to use wide character primitives in the first place.
b) tests of portable_binary_demo fail on high endien platforms. This demo illustrates how to add functionality to an archive via derivation. However, changes to binary_archive at a basic level break this idea for binary archives. This this demo is broken and in no longer serves its original purpose. I haven't had time to replace it.
If it's broken or outdated it should probably be removed from SVN for now: ultimately it would be confusing to end users to have a broken example in the distribution. HTH, John.
John Maddock wrote:
Ah, I think the errors in the log reports are misleading, when building with Minw I see:
<snipped>
So this is a linker error in building the *narrow character* serialization library: there are several tests in Date-time and elsewhere that are then also failing because of this.
This seems to be fixed by the following patch: $ svn diff boost/arch* libs/serial*/src Index: boost/archive/codecvt_null.hpp =================================================================== --- boost/archive/codecvt_null.hpp (revision 41302) +++ boost/archive/codecvt_null.hpp (working copy) @@ -56,6 +56,8 @@ {} }; +#ifndef BOOST_NO_STD_WSTREAMBUF + template<> class codecvt_null<wchar_t> : public std::codecvt<wchar_t, char, std::mbstate_t
{ @@ -87,6 +89,8 @@ } }; +#endif + } // namespace archive } // namespace boost Index: libs/serialization/src/codecvt_null.cpp =================================================================== --- libs/serialization/src/codecvt_null.cpp (revision 41302) +++ libs/serialization/src/codecvt_null.cpp (working copy) @@ -17,7 +17,9 @@ namespace boost { namespace archive { -std::codecvt_base::result +#ifndef BOOST_NO_STD_WSTREAMBUF + + std::codecvt_base::result codecvt_null<wchar_t>::do_out( std::mbstate_t & state, const wchar_t * first1, @@ -79,5 +81,7 @@ return std::codecvt_base::ok; } +#endif + } // namespace archive } // namespace boost OK to commit? (BTW we can't just move codecvt_null.cpp to the wide character library as that would break msvc dll builds :-( ) HTH, John.
John Maddock wrote: (BTW we can't just move codecvt_null.cpp to the wide
character library as that would break msvc dll builds :-( )
Hmmm - this surprised me and I looked around. I believe that this issue might have something to do with template<> class codecvt_null<wchar_t> : public std::codecvt<wchar_t, char, std::mbstate_t> { virtual BOOST_ARCHIVE_DECL(std::codecvt_base::result) do_out( .... Perhaps changing BOOST_ARCHIVE_DECL to BOOST_WARCHIVE_DECL might help something? Robert Ramey
Robert Ramey wrote: [...]
When I look at the trunk results I see the following:
a) failure due to the fact that wide character serialization won't build for certain platforms. On the branch, I tweaked to test/Jamfile to make some tests depended on test results on in test/config. So that tests which don't make sense aren't run. This works on my system but I have no idea whether its kosher. In Jamfiles for V1, this was addressed but that code was broken when things moved to V2. I don't know if this combination was tested with 1.34 so I don't know if reverting would help here.
b) tests of portable_binary_demo fail on high endien platforms. This demo illustrates how to add functionality to an archive via derivation. However, changes to binary_archive at a basic level break this idea for binary archives. This this demo is broken and in no longer serves its original purpose. I haven't had time to replace it.
I believe that the above accounts for all the known failures.
c)I've noticed that bjam doesn't detect failure of test_exported which is an imported test. I've got it passing on my branch but I don't know what the true status is on the trunk.
The test_exported tests are failing for a wide range of testers. (gcc 4.1.1, gcc 4.2.1, gcc 4.3.0, hp_cxx) What do you mean by saying that this failure isn't detected by bjam?
d)Changes in implemenation of binary_archives prevent the library from building on older platforms. This doesn't show up in the boost test matrix.
Markus
Markus Schöpflin wrote:
Robert Ramey wrote:
c)I've noticed that bjam doesn't detect failure of test_exported which is an imported test. I've got it passing on my branch but I don't know what the true status is on the trunk.
The test_exported tests are failing for a wide range of testers. (gcc 4.1.1, gcc 4.2.1, gcc 4.3.0, hp_cxx) What do you mean by saying that this failure isn't detected by bjam?
When I tested on my own system, i was getting a test that trapped on an assert(false) being marked "pass". This was when compiled for debug. When I compiled for release, the test failed with "unregistered cast". I wasn't particularly confident that I wasn't making some sort of mistake or drawing some false conclusion, but I believe that it was subsequently confirmed and a bjam fix was checked in - (at least for *nix).
From looking at http://beta.boost.org/development/tests/trunk/developer/serialization.html I'm don't know for a fact which variant is being run.
So it seems that here are couple of real possibilities: a) export functionality fails on gcc 4.1+ compilers. Seems quite likely from looking at the table and the fact the implementation of export is compiler dependent. b) It concievable that its failing on all platforms but not being detected. In any case, I don't have gcc 4.1+ available so its hard for me to look at. Robert Ramey
Robert Ramey schrieb:
Markus Schöpflin wrote:
Robert Ramey wrote:
c)I've noticed that bjam doesn't detect failure of test_exported which is an imported test. I've got it passing on my branch but I don't know what the true status is on the trunk. The test_exported tests are failing for a wide range of testers. (gcc 4.1.1, gcc 4.2.1, gcc 4.3.0, hp_cxx) What do you mean by saying that this failure isn't detected by bjam?
When I tested on my own system, i was getting a test that trapped on an assert(false) being marked "pass". This was when compiled for debug. When I compiled for release, the test failed with "unregistered cast". I wasn't particularly confident that I wasn't making some sort of mistake or drawing some false conclusion, but I believe that it was subsequently confirmed and a bjam fix was checked in - (at least for *nix).
From looking at http://beta.boost.org/development/tests/trunk/developer/serialization.html I'm don't know for a fact which variant is being run.
From looking at the compiler options of the failing tests, I would think that the gcc tests are run in the debug variant. And I'm sure that hp_cxx is running the debug variant, as I'm the one running the tests.
So it seems that here are couple of real possibilities:
a) export functionality fails on gcc 4.1+ compilers. Seems quite likely from looking at the table and the fact the implementation of export is compiler dependent.
There is hopefully someone around with access to one of these gcc versions which is able to help. I could look into the failures on hp_cxx tomorrow, perhaps the failures are related.
b) It concievable that its failing on all platforms but not being detected.
In any case, I don't have gcc 4.1+ available so its hard for me to look at.
Robert Ramey
Markus
Markus Schöpflin wrote: [...]
There is hopefully someone around with access to one of these gcc versions which is able to help. I could look into the failures on hp_cxx tomorrow, perhaps the failures are related.
Here is part of the call stack for one of the Tru64/cxx failures: ... #7 0x1200cd620 in __cxx_throw(...) in ../../../bin.v2/libs/serialization/test/test_exported_binary_archive.test/hp_cxx-71_006_tru64/debug/test_exported_binary_archive #8 0x12003dc84 in __7throw_exception__tm__37_Q3_5boost7archive17archive_exception__5boostFRCZ1Z_v(e=& class archive_exception { ... }) "../../../boost/throw_exception.hpp":39 #9 0x12003f1f0 in boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive,polymorphic_base*>::polymorphic<polymorphic_base>::save(ar=& class binary_oarchive { ... }, t=& class polymorphic_base { ... }, bpos_ptr=0x0) "../../../boost/archive/detail/oserializer.hpp":405 #10 0x12003f2fc in __7__CPR237__save__tm__19_16polymorphic_base__Q4_5boost7archive6detail79save_pointer_type__tm__54_Q3_J36JJ42J15binary_oarchivePJ13JSFRQ3_J36JJ42JJ102JRCZ1_2ZPCQJ34JostJ42JJ50J25basic_pointer_oserializer_v(ar=& class binary_oarchive { ... }, t=& class polymorphic_base { ... }, bpos_ptr=0x0) "../../../boost/archive/detail/oserializer.hpp":434 #11 0x12003f370 in boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive,polymorphic_base*>::invoke(ar=& class binary_oarchive { ... }, t=0x140061c00) "../../../boost/archive/detail/oserializer.hpp":462 #12 0x12003f4c8 in __7save__tm__54_Q3_5boost7archive15binary_oarchiveP16polymorphic_base__Q2_5boost7archiveFRZ1ZRCZ2Z_v(ar=& class binary_oarchive { ... }, t=& 0x140061c00) "../../../boost/archive/detail/oserializer.hpp":532 #13 0x12003fbf0 in __7save_override__tm__21_CP16polymorphic_base__Q4_5boost7archive6detail58common_oarchive__tm__35_Q3_5boost7archive15binary_oarchiveFRZ1_2Zi_v(t=& 0x140061c00, =0) "../../../boost/archive/detail/com ... The exception details are: (ladebug) print e & class boost::archive::archive_exception { code = unregistered_cast; } Does this help in any way? Do you need more information? Thanks, Markus
Ping? Markus Schöpflin wrote:
Here is part of the call stack for one of the Tru64/cxx failures:
... #7 0x1200cd620 in __cxx_throw(...) in ../../../bin.v2/libs/serialization/test/test_exported_binary_archive.test/hp_cxx-71_006_tru64/debug/test_exported_binary_archive #8 0x12003dc84 in __7throw_exception__tm__37_Q3_5boost7archive17archive_exception__5boostFRCZ1Z_v(e=& class archive_exception { ... }) "../../../boost/throw_exception.hpp":39 #9 0x12003f1f0 in boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive,polymorphic_base*>::polymorphic<polymorphic_base>::save(ar=& class binary_oarchive { ... }, t=& class polymorphic_base { ... }, bpos_ptr=0x0) "../../../boost/archive/detail/oserializer.hpp":405 #10 0x12003f2fc in __7__CPR237__save__tm__19_16polymorphic_base__Q4_5boost7archive6detail79save_pointer_type__tm__54_Q3_J36JJ42J15binary_oarchivePJ13JSFRQ3_J36JJ42JJ102JRCZ1_2ZPCQJ34JostJ42JJ50J25basic_pointer_oserializer_v(ar=& class binary_oarchive { ... }, t=& class polymorphic_base { ... }, bpos_ptr=0x0) "../../../boost/archive/detail/oserializer.hpp":434 #11 0x12003f370 in boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive,polymorphic_base*>::invoke(ar=& class binary_oarchive { ... }, t=0x140061c00) "../../../boost/archive/detail/oserializer.hpp":462 #12 0x12003f4c8 in __7save__tm__54_Q3_5boost7archive15binary_oarchiveP16polymorphic_base__Q2_5boost7archiveFRZ1ZRCZ2Z_v(ar=& class binary_oarchive { ... }, t=& 0x140061c00) "../../../boost/archive/detail/oserializer.hpp":532 #13 0x12003fbf0 in __7save_override__tm__21_CP16polymorphic_base__Q4_5boost7archive6detail58common_oarchive__tm__35_Q3_5boost7archive15binary_oarchiveFRZ1_2Zi_v(t=& 0x140061c00, =0) "../../../boost/archive/detail/com ...
The exception details are:
(ladebug) print e & class boost::archive::archive_exception { code = unregistered_cast; }
Does this help in any way? Do you need more information?
Thanks, Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think I replied to his under the subject of Re: [serialization] Clearing Intel/Windows errors? Robert Ramey
John Maddock wrote: Oh - apparently the serialization/complex.hpp is failing on some platforms. I don't know anything about that. Robert Ramey
On 23 Nov 2007, at 12:55, Robert Ramey wrote:
John Maddock wrote:
Oh - apparently the serialization/complex.hpp is failing on some platforms. I don't know anything about that.
It is only failing because of the build problems due to wide character support on one platform - same origin as the other failures on that platform. Matthias
Hi John, On 23 Nov 2007, at 12:27, John Maddock wrote:
And... without wishing to point fingers... Serialization currently accounds for about half of the outstanding regressions at http://boost.org/regression/trunk/developer/issues.html, so I guess we need to make some sort of decision whether 1.35 will contain:
1) The Boost-1.34 version of serialization (in which case we should revert the Trunk for the time being). 2) Current Trunk version (plus fixes? Looks like many of the failures have a single cause?) 3) The current development branch version that you're actively working on.
Solution 1 would imply that Boost.MPI could not be part of Boost 1.35 Matthias
Robert Ramey wrote:
I've resolved to move these headers from their current locations into the boost/serialization directory. Right now I'm sort of bogged down in other stuff and I've make fairly extensive changes/enhancements to the library. I'm working on a branch. About a month ago I inquired as to the convenience/inconvenience of merging my changes from the branch into the trunk and the response was that as things were soon to be released, it would not be a good time to do so. This was fine with me. So by now my branch is even more divirgent from the trunk. I'll make these changes on this branch which can be merged into trunk at such time as is deemed convenient.
Thanks, Robert. If there are no more replies to my posts too, I'll try to put the matter into writing. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
on Fri Nov 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
I've resolved to move these headers from their current locations into the boost/serialization directory. Right now I'm sort of bogged down in other stuff and I've make fairly extensive changes/enhancements to the library.
Sorry, I got bogged down too, and I neglected to thank you for your flexibility. So, thanks. Please understand that you can do this make without making drastic breaking changes; I suggest you deprecate the old usages while leaving backward-compatibility forwarding headers and maybe using directives in place for one release cycle (or even two if we manage to get up to one release per quarter), to give people a chance to make the switch.
I'm working on a branch. About a month ago I inquired as to the convenience/inconvenience of merging my changes from the branch into the trunk and the response was that as things were soon to be released, it would not be a good time to do so. This was fine with me. So by now my branch is even more divirgent from the trunk. I'll make these changes on this branch which can be merged into trunk at such time as is deemed convenient.
I know it doesn't help right now, but I hope to co-manage the next release, and if that happens I will follow a procedure that will keep the trunk and the release branch much more closely synchronized. That should make it practical for you to keep your development branch much more closely synchronized with the trunk. Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Fri Nov 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
I know it doesn't help right now, but I hope to co-manage the next release, and if that happens I will follow a procedure that will keep the trunk and the release branch much more closely synchronized. That should make it practical for you to keep your development branch much more closely synchronized with the trunk.
working the way I'm currently working has worked well for me. My branch is derived from 1.34.1. This has meant that I've been able to develope in an environment where all other variables other than the ones I explicitly introduce are stable. This is an imense improvement from the way I used to do it. It has resulted in some divirgence. But a lot of that is due to the fact that the changes I've been making are somewhat more ambitious than previous ones. Although I think my current version is more robust and complete than that on the trunk, introducing even one small error or inconsistency on one platform slows the release down by a week as things get sorted out. Also we do have a smal number of issues with the serialization library in the trunk. But things are made much simpler by the fact they're not mixed in with my current set. When these issues in the trunk are resolved, I'll merge them into my branch then merge the branch back to the trunk. Except for figuring out how to do the actual merge, I believe that this will result in a measurably higher quality product. Based in this experience and a better understanding of SVN, I expect to tweak my procedure for next time. Hopefully this will reduce the pain even further. Robert Ramey
participants (7)
-
David Abrahams -
Joel de Guzman -
John Maddock -
Markus Schöpflin -
Markus Schöpflin -
Matthias Troyer -
Robert Ramey