RC_1_34_0 to trunk reconciliation

I attempted a 3-way merge of

BOOST_ROOT/tools/build

between

Base : RC_1_34_0_freeze
Tree1: RC_1_34_0
Tree2: trunk

Essentially I found 6 files that need to be changed:

BOOST_ROOT/tools/build/v2/tools/gcc.jam
BOOST_ROOT/tools/build/v2/tools/python.jam
BOOST_ROOT/tools/build/v2/tools/testing.jam
BOOST_ROOT/tools/build/v2/tools/vacpp.jam
BOOST_ROOT/tools/build/v2/util/os.jam
BOOST_ROOT/tools/build/v2/util/sequence.jam

This is what would happen when applying the changes:
All six files equal the versions from RC_1_34_0 i.e. latest
release.
Rest of trunk unchanged.

If there are no objections I'll commit the changes.

Btw.: I am also trying to run the tests with mingw on
windows, and this is 
looking rather good so far.

Roland aka speedsnail


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

Roland Schwarz wrote:
> I attempted a 3-way merge of
> 
> BOOST_ROOT/tools/build
> 
> between
> 
> Base : RC_1_34_0_freeze
> Tree1: RC_1_34_0
> Tree2: trunk
> 
> Essentially I found 6 files that need to be changed:
> 
> BOOST_ROOT/tools/build/v2/tools/gcc.jam
> BOOST_ROOT/tools/build/v2/tools/python.jam
> BOOST_ROOT/tools/build/v2/tools/testing.jam
> BOOST_ROOT/tools/build/v2/tools/vacpp.jam
> BOOST_ROOT/tools/build/v2/util/os.jam
> BOOST_ROOT/tools/build/v2/util/sequence.jam
> 
> This is what would happen when applying the changes:
> All six files equal the versions from RC_1_34_0 i.e.
latest release.

The problem is that there are changes made to trunk also.
Hence a 3-way 
merge would leave those files different from both trunk and
RC_1_34_0.

> If there are no objections I'll commit the changes.

I object... I don't want to loose the trunk changes 



-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Rene Rivera wrote:
> I object... I don't want to loose the trunk changes


This is why I made a three way compare. Not to loose the
changes from trunk.

If you look closely to the proposed files you can see that
most of them 
differ only in small items (which I tried to track down).

python.jam and gcc.jam differ in more changes.

About Python.jam there is a statement from David to use the
one from 
RC_1_34_0 since he knows the one in trunk hasn't been
maintained.

Left gcc.jam and os.jam.

Every other files that differ between RC and trunk are taken
from trunk.
So nothing is lost.

What I was suggesting: Just those 6 files likely need
consideration.

Roland aka speedsnail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Sat Aug 18 2007, Roland Schwarz
<roland.schwarz-AT-chello.at> wrote:

> About Python.jam there is a statement from David to use
the one from 
> RC_1_34_0 since he knows the one in trunk hasn't been
maintained.

Careful; I said it _might_ not have been maintained.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

The Astoria Seminar ==> http://www.astoriasemin
ar.com

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

Roland Schwarz wrote:
> Essentially I found 6 files that need to be changed:
> 
> BOOST_ROOT/tools/build/v2/tools/gcc.jam
> BOOST_ROOT/tools/build/v2/tools/python.jam
> BOOST_ROOT/tools/build/v2/tools/testing.jam
> BOOST_ROOT/tools/build/v2/tools/vacpp.jam
> ...
> 
> If there are no objections I'll commit the changes.
> 

Hello Roland,

Since it looks like you are already working on the
Build.Build v2 tool 
jam files for the trunk, would you be able to apply the
following patch 
to stlport.jam to fix support for STLport 5.x?  This will
solve the 
linking issue and a few other miscellaneous problems (see 

http://lists.boost.org/boost-build/2006/09/15036.php)

Thanks,
-Dave


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

Rene Rivera wrote:
> I object... I don't want to loose the trunk changes


The issue as I see it, is not to loose changes from trunk,
but from RC_1_34.

Triggered by Renes objection I tried to find the correct
base point for 
three way compare, since RC_1_34_0_freeze indeed is not.

Thomas Witt announced existence of RC_1_34_0 branch on
2006-03-21, which funnily is the date of begin of spring. (
Maybe 
because trees tend to get new branches?  )

The last commit mail before is on 2006-03-20, and the first
after is on 
2006-03-22. The first commit to RC_1_34_0 branch I can see
also is on 
2006-03-22.

So I think a safe base for three-way compare would be to use
CVS 
checkout by date: 2006-03-21.

I did this, and unfortunately things show up to be much more
complicated.

So I want to raise the question why it wouldn't be a better
base to use 
merged_to_RC_1_34_0 instead. At least as I understand this
was the 
reason why this tag was created at all, not?

If I do this, 3-way merge reduces to 7 manual merges
necessary, which 
look easy to resolve.

Opinions?

Roland aka speedsnail




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

Roland Schwarz wrote:
> Rene Rivera wrote:
>> I object... I don't want to loose the trunk changes


> So I want to raise the question why it wouldn't be a
better base to use 
> merged_to_RC_1_34_0 instead. At least as I understand
this was the 
> reason why this tag was created at all, not?

That was exactly why that tag was created. But it only helps
if people 
follow the merge procedures. Which we didn't.



-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Rene Rivera wrote:
> Roland Schwarz wrote:
>> Rene Rivera wrote:
>>> I object... I don't want to loose the trunk
changes 
> 
>> So I want to raise the question why it wouldn't be
a better base to use 
>> merged_to_RC_1_34_0 instead. At least as I
understand this was the 
>> reason why this tag was created at all, not?
> 
> That was exactly why that tag was created. But it only
helps if people 
> follow the merge procedures. Which we didn't.

I just did a merge of the 1.34.1 changes to trunk 
<
http://svn.boost.org/trac/boost/changeset/38792>.
Except for 
python.jam, which as expected has a large number of changes
to think 
about. Note I took the more mundane two-way-diff approach
and just 
considered the changes individually.

And I'm still waiting for Roland to mention what the *seven*
files are, 
since he originally mentioned *six*, and I could only see
the original 
*six* are having relevant changes (with the two-way-diff).


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build