[1.35.0] branches/release open for known-good merges
Until further notice, branches/release is open for known-good merges. "known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing. Thus if you make a bug fix in trunk, wait a day or two before committing a merge of the fix to branches/release and look at the regression test results before you commit. Make sure in particularly the change doesn't break other libraries. Thanks, --Beman
Beman Dawes wrote:
Until further notice, branches/release is open for known-good merges.
"known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing.
Thus if you make a bug fix in trunk, wait a day or two before committing a merge of the fix to branches/release and look at the regression test results before you commit. Make sure in particularly the change doesn't break other libraries.
I should have explain the plan a bit more. The idea is to leave branches/release open for (cautious) merges while we reduce the failure rate to zero. That is, all failures on our high priority platforms either fixed or marked up as expected failures. Meanwhile, next week we'll shakedown the release generation scripts, and look at other aspects of release quality. Doc issues, such integration of the new web site material and broken links are a real concern. As we get closer to a release, we will freeze code changes so developers have to ask for individual permission to do merges. But we haven't reached that point yet. --Beman
Beman Dawes wrote:
Beman Dawes wrote:
Until further notice, branches/release is open for known-good merges.
"known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing.
Apparently, some of us morons need more help with this crazy merge thing. I need to merge revisions 41419-41420 from trunk to release, so I did what seemed the most logical thing: svn co https://svn.boost.org/svn/boost/branches/release cd release svnmerge.py merge -r 41419-41420 The svnmerge.py invocation does *nothing* ... no merge, no output, no errors. Any help? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Beman Dawes wrote:
Beman Dawes wrote:
Until further notice, branches/release is open for known-good merges.
"known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing.
Apparently, some of us morons need more help with this crazy merge thing. I need to merge revisions 41419-41420 from trunk to release, so I did what seemed the most logical thing:
svn co https://svn.boost.org/svn/boost/branches/release cd release svnmerge.py merge -r 41419-41420
The svnmerge.py invocation does *nothing* ... no merge, no output, no errors. Any help?
Because I always want all my trunk changes merged into branches/release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge. Also, I don't want to have to do multiple merges for boost-root/libs/library-name, boost-root/boost/library-name, and then also individual header files in boost-root//boost, I use a script to automate merges. See attached. The script requires environmental variable BOOST_MERGED_TO_RELEASE be a path to the current trunk, and the current branches/release also checked out, say in /boost/release. Then: cd /boost/release merge_release --dry-run filesystem will do a dry run of the merge. You can then do: merge_release filesystem for the actual merge. Then after local testing, the commit is done normally. Below is what it looked like for a merge I just did. Note the message giving the revision number, which I use in the commit message. HTH, even if it doesn't directly answer your question. --Beman D:\>cd \boost\release D:\boost\release>merge_release.py filesystem command: svn info --xml d:\boost\merged-to-release
e:\temp/merged_to_release-svn_info.xml Using d:\boost\merged-to-release revision 41517 as trunk merge point Merging boost-root/boost/ filesystem ...
command: svn merge https://svn.boost.org/svn/boost/branches/release/boost/filesy stem https://svn.boost.org/svn/boost/trunk/boost/filesystem@41517 boost/filesystem Merging boost-root/libs/ filesystem ... command: svn merge https://svn.boost.org/svn/boost/branches/release/libs/filesys tem https://svn.boost.org/svn/boost/trunk/libs/filesystem@41517 libs/filesystem U libs/filesystem/doc/index.htm U libs/filesystem/src/path.cpp A libs/filesystem/example/vc++.bat U libs/filesystem/example/simple_ls.cpp U libs/filesystem/example/file_size.cpp command: svn merge https://svn.boost.org/svn/boost/branches/release/boost/filesystem.hpp https://svn.boost.org/svn/boost/trunk/boost/filesystem.hpp@41517 boost/filesystem.hpp # merge diff between branches/release and trunk into working copy # Copyright Beman Dawes 2007 # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # ---------------------------------------------------------------------------- # import os import sys import platform import time import ftplib # invoke the system command line processor def cmd(command): print "command:", command os.system(command) # get revision number of a path, which may be a filesystem path or URL def revision(path, results_path, test_name): rev = 0 svn_info_file = results_path + "/" + test_name + "-svn_info.xml" command = "svn info --xml " + path + " >" + svn_info_file cmd(command) f = open( svn_info_file, 'r' ) svn_info = f.read() f.close() i = svn_info.find( 'revision=' ) if i >= 0: i += 10 while svn_info[i] >= '0' and svn_info[i] <= '9': rev = rev*10 + int(svn_info[i]) i += 1 return rev # invoke svn merge def svn_merge(options, path, trunk_rev): print cmd("svn merge "+options+"https://svn.boost.org/svn/boost/branches/release/" +path+" https://svn.boost.org/svn/boost/trunk/"+path+"@"+str(trunk_rev)+" "+path) # ---------------------------------------------------------------------------- # if len(sys.argv) < 2: print "Usage: merge_release.py [options] LIBRARY-NAME" print " Does svn merge to release from trunk for any boost-root/boost" print " headers associated with the library, the boost/LIBRARY-NAME directory" print " and the libs/LIBRARY-NAME directory. Options are the svn merge options." print "Example: merge_release.py --dry-run filesystem" exit(1) if not os.path.exists("LICENSE_1_0.txt") or not os.path.exists("libs") or not os.path.exists("boost"): print "Error: This program must run from the boost-root directory" exit(1) options = "" i = 1 while i < len(sys.argv)-1: options += sys.argv[i]+" " i += 1 library_name = sys.argv[i] trunk_merged_to_release = os.environ['BOOST_MERGED_TO_RELEASE'] if len(trunk_merged_to_release) == 0: print "Error: Must set BOOST_MERGED_TO_RELEASE to trunk path" exit(1) trunk_revision = revision(trunk_merged_to_release, os.environ['TEMP'], 'merged_to_release') print "Using", trunk_merged_to_release, "revision", trunk_revision, "as trunk merge point" print "Merging boost-root/boost/", library_name, "..." svn_merge(options, "boost/" + library_name, trunk_revision) print print "Merging boost-root/libs/", library_name, "..." svn_merge(options, "libs/" + library_name, trunk_revision) #print grepcmd = "grep -E -l \"www.boost.org/libs/"+library_name+"([ /]|$)\" boost/*.h*" #print "Searching headers with", grepcmd for hdr in os.popen(grepcmd).readlines(): svn_merge(options, hdr[0:len(hdr)-1], trunk_revision)
Beman Dawes wrote:
Because I always want all my trunk changes merged into branches/release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge.
I thought we all agreed to use svnmerge.py. Am I mistaken? And I don't want to merge all my changes from head into the release branch, just those two revisions. Is there no procedure for that? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Beman Dawes wrote:
Because I always want all my trunk changes merged into branches/release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge.
I thought we all agreed to use svnmerge.py. Am I mistaken?
Some folks think we should all be using it, but there isn't general agreement AFAIK. I'm personally not interested in learning a new tool that is due soon for replacement by regular Subversion. I'm concentrating on trying to learn more about the regular Subversion features.
And I don't want to merge all my changes from head into the release branch, just those two revisions. Is there no procedure for that?
I'd be surprised if svnmerge.py didn't support that, but I'm not familiar with how it works. Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments. --Beman
Beman Dawes wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Because I always want all my trunk changes merged into branches/release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge. I thought we all agreed to use svnmerge.py. Am I mistaken?
Some folks think we should all be using it, but there isn't general agreement AFAIK. I'm personally not interested in learning a new tool that is due soon for replacement by regular Subversion. I'm concentrating on trying to learn more about the regular Subversion features.
They're adding the features of svnmerge.py to svn because merge tracking is very important. Trying to put together a release without merge tracking is asking for trouble, IMO. To quote Dave:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell.
FWIW, I've been using svnmerge.py to manage a private branch and it's been pretty easy to use.
And I don't want to merge all my changes from head into the release branch, just those two revisions. Is there no procedure for that?
I'd be surprised if svnmerge.py didn't support that, but I'm not familiar with how it works.
It does.
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments.
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Dec 2, 2007, at 6:36 PM, Eric Niebler wrote:
Beman Dawes wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Because I always want all my trunk changes merged into branches/ release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge. I thought we all agreed to use svnmerge.py. Am I mistaken?
Some folks think we should all be using it, but there isn't general agreement AFAIK. I'm personally not interested in learning a new tool that is due soon for replacement by regular Subversion. I'm concentrating on trying to learn more about the regular Subversion features.
They're adding the features of svnmerge.py to svn because merge tracking is very important. Trying to put together a release without merge tracking is asking for trouble, IMO. To quote Dave:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell.
FWIW, I've been using svnmerge.py to manage a private branch and it's been pretty easy to use.
And I don't want to merge all my changes from head into the release branch, just those two revisions. Is there no procedure for that?
I'd be surprised if svnmerge.py didn't support that, but I'm not familiar with how it works.
It does.
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments.
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
Why don't you use a decent SCM that has proper merging and branching features? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
Beman? Eric Niebler wrote:
Beman Dawes wrote:
Beman Dawes wrote:
Because I always want all my trunk changes merged into branches/release, I'm not using svnmerge.py, and am doing a tree-to-tree rather than revsion-to-revision merge. I thought we all agreed to use svnmerge.py. Am I mistaken? Some folks think we should all be using it, but there isn't general agreement AFAIK. I'm personally not interested in learning a new tool
Eric Niebler wrote: that is due soon for replacement by regular Subversion. I'm concentrating on trying to learn more about the regular Subversion features.
They're adding the features of svnmerge.py to svn because merge tracking is very important. Trying to put together a release without merge tracking is asking for trouble, IMO. To quote Dave:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell.
FWIW, I've been using svnmerge.py to manage a private branch and it's been pretty easy to use.
And I don't want to merge all my changes from head into the release branch, just those two revisions. Is there no procedure for that? I'd be surprised if svnmerge.py didn't support that, but I'm not familiar with how it works.
It does.
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments.
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
-- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Beman?
Eric Niebler wrote:
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
AFAICT someone already ran svnmerge init on the branch. Note, anyone could have done that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Eric Niebler wrote:
Beman?
Eric Niebler wrote:
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
AFAICT someone already ran svnmerge init on the branch. Note, anyone could have done that.
Then the problem must be on my end, because svnmerge.py still doesn't seem to work for me. What I'm doing is: cd branches/release svnmerge.py merge -r 41419-41420 I expect this to merge the specified revisions from trunk to release, but it doesn't. Can anybody tell me what I'm doing wrong? Was it because release was branched from RC_1_34_0 and not trunk? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Rene Rivera wrote:
Eric Niebler wrote:
Beman? Eric Niebler wrote:
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release. AFAICT someone already ran svnmerge init on the branch. Note, anyone could have done that.
Then the problem must be on my end, because svnmerge.py still doesn't seem to work for me. What I'm doing is:
cd branches/release svnmerge.py merge -r 41419-41420
I expect this to merge the specified revisions from trunk to release, but it doesn't. Can anybody tell me what I'm doing wrong?
It may be that not all of the branch is treated with svnmerge. It's hard for me to tell since I don't use it and I'm only looking at the property tags in the trac browser.
Was it because release was branched from RC_1_34_0 and not trunk?
Perhaps. I'm personally sticking to using whole tree merging now that Volodya showed me how to do those. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Eric Niebler wrote:
Was it because release was branched from RC_1_34_0 and not trunk?
Perhaps. I'm personally sticking to using whole tree merging now that Volodya showed me how to do those.
What's that? Link please! -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Rene Rivera wrote:
Eric Niebler wrote:
Was it because release was branched from RC_1_34_0 and not trunk? Perhaps. I'm personally sticking to using whole tree merging now that Volodya showed me how to do those.
What's that? Link please!
Essentially I'm only interested in doing what I call a copy-replace operation. That is to make the tree in the release branch, look exactly like the tree in the trunk. To do it you can: cd branches/release/<some-sub-tree> svn merge https://.../.../branches/release/<some-sub-tree> https://.../.../trunk/<some-sub-tree> Which will do the diff between the two states and apply the changes to the CWD you are on, which is also one of the states. In my case I do it with TortoiseSVN. With the first URL being the "from" and the second the "to", and both marked with the "HEAD" revisions (which is not the default for the tsvn merge dialog). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Essentially I'm only interested in doing what I call a copy-replace operation. That is to make the tree in the release branch, look exactly like the tree in the trunk. To do it you can:
cd branches/release/<some-sub-tree> svn merge https://.../.../branches/release/<some-sub-tree> https://.../.../trunk/<some-sub-tree>
Which will do the diff between the two states and apply the changes to the CWD you are on, which is also one of the states. In my case I do it with TortoiseSVN. With the first URL being the "from" and the second the "to", and both marked with the "HEAD" revisions (which is not the default for the tsvn merge dialog).
That's simple and, for lack of anything better, it's what I did. So much for merge tracking. -- Eric Niebler Boost Consulting www.boost-consulting.com
On 06/12/2007, Eric Niebler <eric@boost-consulting.com> wrote:
Then the problem must be on my end, because svnmerge.py still doesn't seem to work for me. What I'm doing is:
cd branches/release svnmerge.py merge -r 41419-41420
I expect this to merge the specified revisions from trunk to release, but it doesn't. Can anybody tell me what I'm doing wrong? Was it because release was branched from RC_1_34_0 and not trunk?
It hadn't been initialised, the property in the root were copied over from trunk when Beman merged - so it had the merges from RC_1_34_0 to trunk stored, but none from trunk. I've initialised the branch now with the following revisions (based on commit messages): 1-41356 - Beman 41397 - joaquin 41407,41432,41477,41478 - chris_kohlhoff 41419-41420 - you're comments above. If anyone has previously merged in changes and wants to mark them up, the command is something like: svnmerge merge -M -r revsion-numbers For more info 'svnmerge help merge'. Hope that helps, I'll leave it up to you to decide if you actually want to use it. Daniel
Daniel James wrote:
On 06/12/2007, Eric Niebler <eric@boost-consulting.com> wrote:
Then the problem must be on my end, because svnmerge.py still doesn't seem to work for me. What I'm doing is:
cd branches/release svnmerge.py merge -r 41419-41420
I expect this to merge the specified revisions from trunk to release, but it doesn't. Can anybody tell me what I'm doing wrong? Was it because release was branched from RC_1_34_0 and not trunk?
It hadn't been initialised, the property in the root were copied over from trunk when Beman merged - so it had the merges from RC_1_34_0 to trunk stored, but none from trunk.
I've initialised the branch now with the following revisions (based on commit messages):
1-41356 - Beman 41397 - joaquin 41407,41432,41477,41478 - chris_kohlhoff 41419-41420 - you're comments above.
If anyone has previously merged in changes and wants to mark them up, the command is something like:
svnmerge merge -M -r revsion-numbers
For more info 'svnmerge help merge'.
Hope that helps, I'll leave it up to you to decide if you actually want to use it.
It helps immensely. Thanks Daniel. -- Eric Niebler Boost Consulting www.boost-consulting.com
on Thu Dec 06 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments.
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
Two new points of interest, from someone who knows a lot more about these things than I do (http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/29...): 1. You may not want to hold your breath for merge tracking to appear in SVN; it might not be included in 1.5 2. It's quite possible that svnmerge.py isn't the best approach for merging. Local use of Mercurial or Git (or svk?) might work better. Cheers, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Thu Dec 06 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments. My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
Two new points of interest, from someone who knows a lot more about these things than I do (http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/29...):
1. You may not want to hold your breath for merge tracking to appear in SVN; it might not be included in 1.5
2. It's quite possible that svnmerge.py isn't the best approach for merging. Local use of Mercurial or Git (or svk?) might work better.
If we expect people to successfully manage merging from trunk to release (we do, right?), there's needs to be a documented procedure. I confess that I don't know how to do it, and I have a backlog of changes I need to merge from trunk. :-( -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
If we expect people to successfully manage merging from trunk to release (we do, right?), there's needs to be a documented procedure. I confess that I don't know how to do it, and I have a backlog of changes I need to merge from trunk. :-(
When synchronizing SVN head with the code in the sandbox I used TortoiseSVN's merge functionality, and it works very well: you even get to do a "dry run" if you want to see what will happen first. However, that doesn't help if you are using the command line client, but basically it's just a wrapper around svn merge .... you have to keep a note of what revisions were merged when (I put that in the docs so I don't forget), but other than that it seems very straightforward. Not sure this helps, John.
If we expect people to successfully manage merging from trunk to release (we do, right?), there's needs to be a documented procedure. I confess that I don't know how to do it,
Same here, I'm a SVN newbie and definitely don't want to screw up things with "bad" merges. After reading about svnmerge.py I'm wondering whether <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch> still (or again) is the generally accepted way to merge or not. A clarification would be appreciated. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
on Thu Dec 06 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Thu Dec 06 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Have you tried it with regular svn merge? Once you get regular svn merge doing exactly what you want, presumably svnmerge.py would use a very similar set of arguments.
My point is that I can't use svnmerge.py because merge tracking hasn't been enabled on the release branch. Nobody can use svnmerge.py until someone (probably you) runs svnmerge.py init on branches/release.
Two new points of interest, from someone who knows a lot more about these things than I do (http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/29...):
1. You may not want to hold your breath for merge tracking to appear in SVN; it might not be included in 1.5
I did a little research on this: http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133179 is quite revealing.
2. It's quite possible that svnmerge.py isn't the best approach for merging. Local use of Mercurial or Git (or svk?) might work better.
I'm certainly going to try svk when I get a chance. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Beman Dawes wrote:
Until further notice, branches/release is open for known-good merges.
"known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing.
Thus if you make a bug fix in trunk, wait a day or two before committing a merge of the fix to branches/release and look at the regression test results before you commit. Make sure in particularly the change doesn't break other libraries.
Sorry if this question is a bit silly, but where can I see the results of the release branch testing? Clicking "Release view" on the trunk does not show nothing. Interprocess still has 13 failures that I have to fix so I'd like to see how the release version is looking while I try to fix the issues on trunk. Sorry if this has been previously answered,
Thanks,
--Beman
Ion
Ion Gaztañaga wrote:
Beman Dawes wrote:
Until further notice, branches/release is open for known-good merges.
"known-good" means changes that are already passing trunk regression tests, or are in files like documentation that have no effect on testing.
Thus if you make a bug fix in trunk, wait a day or two before committing a merge of the fix to branches/release and look at the regression test results before you commit. Make sure in particularly the change doesn't break other libraries.
Sorry if this question is a bit silly, but where can I see the results of the release branch testing? Clicking "Release view" on the trunk does not show nothing. Interprocess still has 13 failures that I have to fix so I'd like to see how the release version is looking while I try to fix the issues on trunk.
Sorry if this has been previously answered,
NP... http://beta.boost.org/development/testing.html ...Has all the links to the various test results. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
NP... http://beta.boost.org/development/testing.html ...Has all the links to the various test results.
thanks! Ion
On 01/12/2007 00:35, Ion Gaztañaga wrote:
Sorry if this question is a bit silly, but where can I see the results of the release branch testing? Clicking "Release view" on the trunk does not show nothing. Interprocess still has 13 failures that I have to fix so I'd like to see how the release version is looking while I try to fix the issues on trunk.
I think you're looking for this: http://beta.boost.org/development/tests/release/developer/summary_release.ht... Regards, Niko
participants (10)
-
Andreas Huber -
Beman Dawes -
Benoit Sigoure -
Daniel James -
David Abrahams -
Eric Niebler -
Ion Gaztañaga -
John Maddock -
Niko Demmel -
Rene Rivera