On Wed, Jul 22, 2009 at 2:36 PM, Doug Gregor<doug.gregor@gmail.com> wrote:

On Wed, Jul 22, 2009 at 7:54 AM, Beman Dawes<bdawes@acm.org> wrote:

...

...

We would like to perform the Subversion upgrade soon (within the next few days). Are we at a point in Boost's development cycle where we can tolerate a day of down-time to perform this upgrade?

Yes, as long as it is fairly soon. What date do you have in mind?

This Saturday, July 25th. Any strong objections?

Works for me. --Beman

On Jul 22, 2009, at 8:54 AM, Beman Dawes wrote:

On Wed, Jul 22, 2009 at 10:15 AM, Doug Gregor<doug.gregor@gmail.com> wrote:

...

Hi all,

We'd like to upgrade Subversion on svn.boost.org from the old version it is currently using (1.4.2) to version 1.6.2, so that Boost can make use of some of the new and useful features introduced in Subversion 1.5 and 1.6. Since this upgrade will involve an upgrade of the repository, it is likely to take a while---we'll probably have to block out 8 or more hours, during which Subversion will be inaccessible.

We would like to perform the Subversion upgrade soon (within the next few days). Are we at a point in Boost's development cycle where we can tolerate a day of down-time to perform this upgrade?

Yes, as long as it is fairly soon. What date do you have in mind?

FYI, I'm stuck with svn version 1.4.2 for both running the tests and the reporting, for the time being (we've moved to git and no longer use svn). Do you know if 1.4.2 will work with 1.6.2? If not, there may be down time with the tests and reporting until I can get 1.6.2 installed and working. -- Noel

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.

Let's give a big thanks to DongInn Kim, system administrator at the Open Systems Lab @ Indiana University, who keeps the Boost servers running (so we can keep writing cutting-edge C++).

Thanks for making this happen. FWIW, I've just did this: $ svn merge --record-only https://svn.boost.org/svn/boost/trunk/libs/program_options . and then: $ time svn merge ^/trunk/libs/program_options real 0m7.333s user 0m0.200s sys 0m0.036s This is definitely much better than direct diff of two branches -- necessary in past. (Note that I have 1.6 client, the "^/" syntax is new in 1.6) Just in case, before running 'merge --record-only', it's best to run diff first to make sure everything is indeed merged. Thanks, Volodya

2009/7/27 Eric Niebler <eric@boostpro.com>:

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

2009/7/28 Frank Mori Hess <fmhess@speakeasy.net>:

On Monday 27 July 2009, Daniel James wrote:

...

You and I have done full tree merges (using svnmerge, but that's irrelevant) so that the merge info is on the root directory.

I thought svnmerge used the svnmerge-blocked and svnmerge-integrated properties, while svn itself uses svn:mergeinfo.

When you merge using svnmerge it uses svn to do the actual merge so you get both. For an example, see the property changes on: https://svn.boost.org/trac/boost/changeset/55206/

I did see a script somewhere for converting svnmerge properties to svn:mergeinfo though.

I came across it last night, it's is at: http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/svnmerge-... I think it has to be run on the server. Although, it wouldn't be too hard to do it manually. But I was trying to concentrate on how (or I suppose if) we're going to use subversion's native merge. We can deal with the historical data once we've decided that. Daniel

2009/7/28 Juergen Hunold <juergen.hunold@ivembh.de>:

Please note that the mergeinfo from svnmerge.py is mostly broken due to lots of manual sub-tree merges. And we have to make sure everyone making merges uses svn-1.6. I recall that svn-1.5.5 (?) had some serious bugs...

I'm very aware of our problems with svnmerge.py. That's why I'd like to have a discussion about how we'll go forward. But I think there are some developers who strongly prefer manual merges so I don't know if we can get everyone to follow the same merge procedure. The svnmerge.py mergeinfo is still useful - while it has a lot of untracked merges the tracked merges are correct. I use it to track what I've already merged, although merging is still more manual than it should be.

And trunk and release a drifting apart quite fast. maybe a re-branch every couple of releases ?

That might be a good idea. We'd have to clean up trunk first. Most of it is actually in a reasonable shape. I think the biggest problem is new developments that aren't ready for release and have been abandoned. Daniel

On Thu, Jul 30, 2009 at 9:26 AM, Kevin Sopp<baraclese@googlemail.com> wrote:

Looks like the commit list is now broken

http://lists.boost.org/boost-commit/

It should be working again. Thanks for reporting the problem! - Doug