Re: [boost] [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function

Subject: Re: [boost] [release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-05-02 15:01:35

On Tue, May 1, 2012 at 1:10 AM, Daniel James <dnljms_at_[hidden]> wrote:

> 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
> the root.
>
> >> Hmmm..what you're saying *looks* to be in conflict with [1] (which,
> >> incidently, I just modified as the TortoiseSVN instructions were
> outdated).
> >> Can you (or Daniel, or anyone) clarify/comment?
> >>
>
> https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch
> >
> > 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.
>
> > The
> > 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
> tree.
>

Okay, I will try to merge from root in the future. It sounds like I
shouldn't bend over backwards to get it working, though (I don't know what
could go wrong...), as long as I can still merge fine at a more local level.

- Jeff