Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-29 11:50:25

on Mon Oct 29 2007, David Abrahams <> wrote:

> I recently started looking at what changes in my libraries may not
> have made it into the trunk from 1.34.1. The easiest way was to go to
> my boost-trunk working copy and
> svn merge
> What I saw in libraries that weren't my own gave me pause for concern.
> There are a large number of files with a 'C' or an 'M' next to them.
> Neither is *necessarily* an indication of a problem, but 'M' (meaning
> "merged") especially is *likely* to indicate unmerged changes, and 'C'
> (meaning "conflict") may also indicate unmerged changes. I went and
> inspected a few of those files and the ones I looked at all seemed
> suspicious to me.
> I strongly suggest that all other Boost authors do the command above
> and inspect "merged (M)," "conflict (C)," and "added (A)" files that
> they may have touched during the 1.34.x release cycle, or we may find
> that we've dropped important improvements. One place you should
> especially check is in your test/ directories, to make sure that you
> haven't unintentionally dropped any tests between then and now. If
> your testing is complete and you make sure nothing is dropped, in
> theory, dropped features and bugfixes won't be able to hide. But
> there are also documentation changes, so I wouldn't take anything for
> granted ;-)

Err, wait: that diff doesn't do what I thought it did. I'm not sure
if we have the tags necessary to get this information. Maybe the best
we can do is:

  # Get a copy of the last release
  svn co boost-1.34.1
  cd boost-1.34.1

  # Merge in all changes to trunk since last merge into release branch
  svn merge

  # Pretend this was a trunk checkout
  svn switch --relocate

  svn diff # inspect the differences between what we've got and the trunk.

Can anybody suggest a better procedure?


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at