Re: [boost] Subversion upgrade on svn.boost.org

Subject: Re: [boost] Subversion upgrade on svn.boost.org
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-07-27 18:34:10

2009/7/27 Eric Niebler <eric_at_[hidden]>:
> Doug Gregor wrote:
>>
>> The Subversion upgrade on svn.boost.org is now complete, and
>> everything is up and running with Subversion 1.6.3. Trac has also been
>> upgraded to the latest version (0.11.5). If you notice any problems
>> with the upgraded Trac or Subversion, please contact me directly.
>
> What is the recommended merge procedure now?

Do we have anyone to make a recommendation? Hopefully, there's someone
here who knows about subversion's merge tracking and can tell us
what's what.

Unfortunately, we already have a small problem with merging tracking.
You and I have done full tree merges (using svnmerge, but that's
irrelevant) so that the merge info is on the root directory. Other's
have merged in subdirectories and their merge info is stored in those
subdirectories. But the merge tracking only seems to take into account
the merge info on the directory you're merging in.

They obviously both have disadvantages. If we do full tree merges then
the merge information will be all mixed up, making it more work to
pick out the relevant merges, and as with svnmerge, I'm pretty sure
that not everyone will want to use it, so more and more revisions will
be incorrectly reported as unmerged.

If we merge on subdirectories then we can all be responsible for our
own sections of boost, but it'll make tracking shared files (failure
markup, top level headers, detail headers etc.) trickier. And could
end up being a real pain for anyone making changes across boost (such
as the cmake people). And would continue the current practice of
having gatekeepers for sections of boost who are often absent, which I
don't think has been very healthy.

Subversion's manual recommends full tree merges for release branches,
but that's for a more traditional branch structure which we have
problems with. I think storing the merge info on subdirectories might
be the practical solution, although I don't like it myself.

Daniel