Subject: Re: [boost] [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
From: Daniel James (dnljms_at_[hidden])
Date: 2012-05-01 04:10:18
On 1 May 2012 07:21, Eric Niebler <eric_at_[hidden]> wrote:
> On 4/30/2012 10:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
>> On Mon, Apr 30, 2012 at 10:19 PM, Eric Niebler <eric_at_[hidden]> wrote:
>>> Merging from the root is Boost's recommended practice, and is not
>>> painful at all if you're using a recent version of svn. Prefer to do it
>>> that way.
I meant it's a pain to have to keep track of exactly which changesets
you want to merge, with a better system the version control system
should keep track of that for you. But part of the reason it's a pain
is that we can't use 'svn mergeinfo' from the root to see what hasn't
been merged, which would be less of a problem if everyone did merge at
>> Hmmm..what you're saying *looks* to be in conflict with  (which,
>> incidently, I just modified as the TortoiseSVN instructions were outdated).
>> Can you (or Daniel, or anyone) clarify/comment?
> Hrm. Either best practice has changed while I was sleeping (possible),
> or else whoever wrote this didn't know about Boost's merge policy.
Most of the wiki's content hasn't been discussed or reviewed in any
way. It's just someone's opinion (as are posts like this). I don't
think we have a generally accepted 'best practice' for merging.
> proscription against merging individual files and subdirectories comes
> from long ago ... possibly a time when svn merge tracking was very
> rudimentary. It's possible that it doesn't make a difference now. Does
> anybody know?
It still makes a difference. Having a lot of merge metadata makes
merging slower and more complicated. It also makes mergeinfo slower
and less accurate in parent directories It would be great if we could
get subversion to tell us exactly which changesets haven't been merged
to release, but we can't because the metadata is too messy. Since it's
quite likely we'll switch from subversion in the near future, I don't
think it's worth the effort to clean it up. So my compromise is to
keep the metadata in a good condition for my individual parts of the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk