[Important] Boost moving to Subversion on Tuesday, July 31st
============================================= Boost will be moving to Subversion on Tuesday, July 31st. ============================================= === What's happening === We are converting the existing Boost CVS repository, hosted by SourceForge, over to Subversion. The contents of the CVS repository will join the Boost sandbox and (beta) web site in the Boost Subversion repository, hosted by the Open Systems Laboratory at Indiana University. === Timeline === At 8:00 AM EDT on Tuesday, July 31, we will be cutting off access to the current Boost CVS repository. The Boost Subversion repository, mailing list archives, Boost Trac, beta.boost.org, and anything else hosted at OSL will also be unavailable during this time. We expect to have everything back online by midnight Tuesday. I will send another note to the mailing lists when the conversion is complete. The mailing lists and the main Boost web site should still work during this time. === What you should do === If you have any outstanding changes to Boost in your local CVS tree, commit them before 8:00am EDT on Tuesday. Any changes to your local CVS tree that have not been committed to CVS will be lost and will have to manually be moved over Subversion. The Boost CVS repository will not be reopened. If you have not done so yet, familiarize yourself with Subversion, read the Boost Trac page about the Boost Subversion repository, and, if you have write access to CVS, request a Subversion account: http://svn.boost.org/trac/boost/wiki/BoostSubversion === Who's in charge? === I will be the primary contact person for questions about and problems with the Boost Subversion repository. Most questions should be directed to the Boost mailing list. Account requests should go to all of the moderators at boost-owner@lists.boost.org. === How you can help === In several Boost tools and many places in Boost's documentation, we refer to the Boost CVS repository. We need help upgrading these tools and fixing the documentation to refer to the Boost Subversion repository. Specifically: * regression.py, used by regression testers, must be updated to use Subversion * Various developer and release-manager documentation talks about Boost's CVS, but should now refer to Subversion. Better yet: migrate this documentation over to the Boost Trac, where it is easier to maintain and update, and won't be a part of the Boost distribution * Write Subversion-specific documentation on the Trac. Quick-start guides, tips and tricks, etc. would be helpful. One particularly important bit: using svnmerge.py to simplify the handling of release branches. Doug Gregor Open Systems Lab @ Indiana University
Doug Gregor wrote:
Account requests should go to all of the moderators at boost-owner@lists.boost.org.
Here's an additional plea to get accounts ASAP. I've been adding components and corresponding owners to Trac. And the one thing holding up having a full set of components is not having people to assign them to.
=== How you can help === In several Boost tools and many places in Boost's documentation, we refer to the Boost CVS repository. We need help upgrading these tools and fixing the documentation to refer to the Boost Subversion repository. Specifically:
* regression.py, used by regression testers, must be updated to use Subversion
I added a ticket for this <http://svn.boost.org/trac/boost/query?milestone=Subversion+Switch>. If anyone wants to work on it please reassign it.
* Various developer and release-manager documentation talks about Boost's CVS, but should now refer to Subversion. Better yet: migrate this documentation over to the Boost Trac, where it is easier to maintain and update, and won't be a part of the Boost distribution
May I suggest that people also consider migrating documentation to the beta website. Or if you don't feel like directly doing that you can: * Add a page to the wiki with the docs. * Add a ticket to Trac pointing out the wiki page, and requesting to move the content to the beta website (making sure the component is set to "website"). That way I, or maybe one of the Doc Project people, can move/clone it. -- -- 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
On Jul 27, 2007, at 2:43 PM, Rene Rivera wrote:
Doug Gregor wrote:
Account requests should go to all of the moderators at boost- owner@lists.boost.org.
Here's an additional plea to get accounts ASAP. I've been adding components and corresponding owners to Trac. And the one thing holding up having a full set of components is not having people to assign them to.
For technical reasons, please log into the Trac at least once after getting your account.
* Various developer and release-manager documentation talks about Boost's CVS, but should now refer to Subversion. Better yet: migrate this documentation over to the Boost Trac, where it is easier to maintain and update, and won't be a part of the Boost distribution
May I suggest that people also consider migrating documentation to the beta website. Or if you don't feel like directly doing that you can:
* Add a page to the wiki with the docs. * Add a ticket to Trac pointing out the wiki page, and requesting to move the content to the beta website (making sure the component is set to "website").
My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers. It doesn't really need to be on the main web site. User- centric documentation that doesn't need to be in the Boost distribution (i..e, most non-library documentation) should move to the beta website. Sound good? - Doug
On 7/27/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers. It doesn't really need to be on the main web site. User- centric documentation that doesn't need to be in the Boost distribution (i..e, most non-library documentation) should move to the beta website.
Sound good?
It sounds very good to me. The Trac wiki is an incredible resource to maintain developer-centric docs. Best regards Matias
Doug Gregor wrote:
On Jul 27, 2007, at 2:43 PM, Rene Rivera wrote:
Doug Gregor wrote:
* Various developer and release-manager documentation talks about Boost's CVS, but should now refer to Subversion. Better yet: migrate this documentation over to the Boost Trac, where it is easier to maintain and update, and won't be a part of the Boost distribution May I suggest that people also consider migrating documentation to the beta website. Or if you don't feel like directly doing that you can:
* Add a page to the wiki with the docs. * Add a ticket to Trac pointing out the wiki page, and requesting to move the content to the beta website (making sure the component is set to "website").
My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers.
Hm, I don't think editing the new website is any harder to modify/update. I worked hard to come up with a structure that makes it easy. All it takes is the svn access and a text editor. Or if editing XHTML directly is dreadful to you, there are many "visual" editors out there that will work.
It doesn't really need to be on the main web site.
Depends, on what you mean by "developer-centric". Sure we have multiple audiences but we have to consider that there isn't much difference between prospective and existing Boost developers. And that making an explicit distinction between them is likely detrimental to making prospective devs into active devs. But overall I prefer to have docs in the svn/website as it allows for better quality control.
User- centric documentation that doesn't need to be in the Boost distribution (i..e, most non-library documentation) should move to the beta website.
Yep.
Sound good?
Mostly ;-) -- -- 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
On 7/27/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Doug Gregor wrote:
On Jul 27, 2007, at 2:43 PM, Rene Rivera wrote: My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers.
Hm, I don't think editing the new website is any harder to modify/update.
IMO editing a wiki page is easier.
I worked hard to come up with a structure that makes it easy.
This is great, and it will be very good for used docs.
All it takes is the svn access and a text editor. Or if editing XHTML directly is dreadful to you, there are many "visual" editors out there that will work.
You need a lot of things. Past week I edit the IBD wiki from my grandmother old computer using just firefox :)
It doesn't really need to be on the main web site.
Depends, on what you mean by "developer-centric".
I think it is every thing that a user-only booster will not find useful. For example, how our svn is organized.
Sure we have multiple audiences but we have to consider that there isn't much difference between prospective and existing Boost developers.
If you separate users and developers you can write better and more direct docs, It is very different how you write when you now a developer is the target. This is the same reason we separate the Rationale from the Tutorial in our lib docs.
And that making an explicit distinction between them is likely detrimental to making prospective devs into active devs.
IMHO it will not. And I plan to actively get more boost-users involved in Boost development.
But overall I prefer to have docs in the svn/website as it allows for better quality control.
It is a compromise. I think that the developing process will benefit from the flexibility that a wiki gives you. And I do not agree we can not developed quality docs in the Trac Wiki. I think that IBD wiki has a very high quality: http://svn.boost.org/trac/boost/wiki/ImprovingBoostDocs And the wiki allows people to easily collaborate making it better, check the work of IBD proofreaders (thanks Jake and Paul!) http://tinyurl.com/3234qk With respect to user docs, I agree that the best place is the website and the boost release package. King regards Matias
Trying to send this to the docs list again... Matias Capeletto wrote:
On 7/27/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Doug Gregor wrote:
On Jul 27, 2007, at 2:43 PM, Rene Rivera wrote: My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers. Hm, I don't think editing the new website is any harder to modify/update.
IMO editing a wiki page is easier.
Yea, probably :-)
It doesn't really need to be on the main web site. Depends, on what you mean by "developer-centric".
I think it is every thing that a user-only booster will not find useful. For example, how our svn is organized.
There have been many instances, over the years, of users asking how CVS is structured, where to get stuff from CVS, etc. And recently the same for SVN and the sandbox. So I disagree on this one. Perhaps I have a more expansive on who users are. I expect them to cover the full range of experience.
Sure we have multiple audiences but we have to consider that there isn't much difference between prospective and existing Boost developers.
If you separate users and developers you can write better and more direct docs, It is very different how you write when you now a developer is the target. This is the same reason we separate the Rationale from the Tutorial in our lib docs.
Perhaps people are just not aware of the currently designed separation in the beta website... <http://beta.boost.org/development/website_updating.html>. So I'm not disagreeing on separation. Just that putting of in "another" web site would put some information too far away from interested people. Which would result in more questions on the list and possibly turning away some people.
But overall I prefer to have docs in the svn/website as it allows for better quality control.
It is a compromise. I think that the developing process will benefit from the flexibility that a wiki gives you. And I do not agree we can not developed quality docs in the Trac Wiki.
Of course it's possible to develop quality docs in just about anything ;-) But I was referring to a different kind of quality. In particular of the documentation being cohesive and well organized with respect to all the other docs. Why would I place so much importance on this? Well, because a good portion of the questions on IRC and the users list are essentially an inability to find the docs on our current web site.
With respect to user docs, I agree that the best place is the website and the boost release package.
Ah, another aspect I've disagreed with in the past ;-) Not the user docs in the web site, but what kind of docs to put in the release package. One of the goals of the new web site is to reduce the amount of docs in the release package, to reduce maintenance. So we have to be careful what we include in the releases. -- -- 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
On Jul 27, 2007, at 3:23 PM, Rene Rivera wrote:
My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers.
Hm, I don't think editing the new website is any harder to modify/update. I worked hard to come up with a structure that makes it easy. All it takes is the svn access and a text editor. Or if editing XHTML directly is dreadful to you, there are many "visual" editors out there that will work.
It doesn't really need to be on the main web site.
Depends, on what you mean by "developer-centric". Sure we have multiple audiences but we have to consider that there isn't much difference between prospective and existing Boost developers. And that making an explicit distinction between them is likely detrimental to making prospective devs into active devs. But overall I prefer to have docs in the svn/website as it allows for better quality control.
There are a lot of things in the day-to-day development of Boost that users just don't need to know about. The various workings of our Subversion repository, release management procedures, header policies, etc. just don't matter to users. I guess they could live somewhere on boost.org, away from the user-centric documentation, but I prefer the ease-of-use of a Wiki. My hypothesis is that, if we make it really, really, really easy to make improvements to that developer- centric documentation, we'll get better at keeping it up-to-date and relevant. That said, just moving the website into the Subversion with auto- update (as we already have for beta.boost.org) takes much of the pain of our web site updating. Changing things on Sourceforge is a nightmare :( - Doug
Doug Gregor wrote:
There are a lot of things in the day-to-day development of Boost that users just don't need to know about. The various workings of our Subversion repository, release management procedures, header policies, etc. just don't matter to users. I guess they could live somewhere on boost.org, away from the user-centric documentation, but
I pointed this out in the my other reply <http://beta.boost.org/development/website_updating.html>. I already have such separation on the new web site.
I prefer the ease-of-use of a Wiki. My hypothesis is that, if we make it really, really, really easy to make improvements to that developer- centric documentation, we'll get better at keeping it up-to-date and relevant.
Wikipedia has proven that idea impractical. Easy editing doesn't produce better docs, just more of them. You need editors, review, etc. to get better docs. -- -- 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
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: 27 July 2007 21:22 To: boost@lists.boost.org Subject: Re: [boost] [Important] Boost moving to Subversion on Tuesday, July 31st
I prefer the ease-of-use of a Wiki. My hypothesis is that, if we make it really, really, really easy to make improvements to that developer- centric documentation, we'll get better at keeping it up-to-date and relevant.
Wikipedia has proven that idea impractical. Easy editing doesn't produce better docs, just more of them. You need editors, review, etc. to get better docs.
I have to disagree - I find Wikipedia an excellent source - provided you don't expect perfection - but where do you get that? I find the Boost documentation is often really lacking user feedback - the things that *users* really want to know. I think a wiki system will prodvide a lot that the authors are incapable of providing - they know too much! But the authors can still provide the editing function and I would like the 'release' to include their latest edited version. Paul PS I still think the thing we are really, really missing is an indexing/searching facility. so many times I have wanted to know something, but even knowing I have read it before, I struggle to find it. Google may help us here, but I would like to see us providing our own indexing tool. Anyone have any ideas on how to use the quickbook docs (or html or pdf?) to provide this?
On Jul 28, 2007, at 3:23 PM, Paul A Bristow wrote:
PS I still think the thing we are really, really missing is an indexing/searching facility. so many times I have wanted to know something, but even knowing I have read it before, I struggle to find it. Google may help us here, but I would like to see us providing our own indexing tool. Anyone have any ideas on how to use the quickbook docs (or html or pdf?) to provide this?
The indexing would be very easy to do in the BoostBook XSLT stylesheets, I expect. - Doug
Douglas Gregor wrote:
On Jul 28, 2007, at 3:23 PM, Paul A Bristow wrote:
PS I still think the thing we are really, really missing is an indexing/searching facility. so many times I have wanted to know something, but even knowing I have read it before, I struggle to find it. Google may help us here, but I would like to see us providing our own indexing tool. Anyone have any ideas on how to use the quickbook docs (or html or pdf?) to provide this?
The indexing would be very easy to do in the BoostBook XSLT stylesheets, I expect.
It's not automatic. See http://www.sagehill.net/docbookxsl/GenerateIndex.html. It's in my TODO list to make it easy to do indexterms in Qbk. IBD Questions: 1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki? 2) Will someone in IBD (or anyone else) be willing to help out and do some Qbk coding? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 7/28/07, Joel de Guzman <joel@boost-consulting.com> wrote:
Douglas Gregor wrote:
On Jul 28, 2007, at 3:23 PM, Paul A Bristow wrote:
PS I still think the thing we are really, really missing is an indexing/searching facility. so many times I have wanted to know something, but even knowing I have read it before, I struggle to find it. Google may help us here, but I would like to see us providing our own indexing tool. Anyone have any ideas on how to use the quickbook docs (or html or pdf?) to provide this?
The indexing would be very easy to do in the BoostBook XSLT stylesheets, I expect.
It's not automatic. See http://www.sagehill.net/docbookxsl/GenerateIndex.html. It's in my TODO list to make it easy to do indexterms in Qbk.
IBD Questions:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki?
There is a page exactly for this: http://svn.boost.org/trac/boost/wiki/ImprovingQuickbook It was created two weeks ago but it is empty right now. Be free to use it for anything related to improving Quickbook. There are this two pages too: http://svn.boost.org/trac/boost/wiki/BoostBuildSupportForDocsTools http://svn.boost.org/trac/boost/wiki/ImprovingBoostbook This three pages are grouped under "Documentation Tools" section on IBD wiki: http://svn.boost.org/trac/boost/wiki/DocumentationTools
2) Will someone in IBD (or anyone else) be willing to help out and do some Qbk coding?
I think that the best way to get people involved is to break the things we have to do for Quickbook into subprojects and add stubs in that page, including a help request. We can organize this effort based on the TODO list. It was very exciting to read your posts during the day Joel, thanks a lot for this movie like action :) While we are at this pace, I take the opportunity to remind you a feature request (from this thread: http://tinyurl.com/2nqwzl ): ------------------------------------------------------------ Can templates notation be extended to use optional named parameters (onp). I am thinking in: Template definition: [template tname [a b c] [onp_1 default_1] [onp_2 default_2] This is the template body... use unamed forced parameters: [a] use onp parameters: [onp_1] (This prints the value or the default) [onp_1? if was used do this : if not do this ] ] IMO this is a good extension and is backward compatible with the current implementation. ------------------------------------------------------------ Count with us. We love Quickbook :) I will give a three hours course about Quickbook in my university ( UBA - Argentina ) in Tuesday. I expect more than 25 developers to assist, the quickbook community will start to grow :) King regards Matias
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki?
Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this. -- -- 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
On 7/28/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki?
Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this.
Hmm... It might just be my impression, but I see the issue tracking system as lacking the "looking for help" advertising component. Even if someone that wanted to help out did look through the tickets to find something they would like to do, can they easily see which tickets are up for grabs (rather than already being actively worked on by someone, or something the owner wants to do himself/herself)? Perhaps if tickets could be flagged by the owner as "help wanted" (or reassigned to a "help wanted" owner)? If this is possible, maybe the "looking for help" wiki pages could simply provide a (automatically generated?) list of tickets that are marked this way, organized in some appropriate way (by project or whatever). Just a thought. Stjepan
On 7/29/07, Stjepan Rajko <stipe@asu.edu> wrote:
On 7/28/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki?
Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this.
Hmm... It might just be my impression, but I see the issue tracking system as lacking the "looking for help" advertising component. Even if someone that wanted to help out did look through the tickets to find something they would like to do, can they easily see which tickets are up for grabs (rather than already being actively worked on by someone, or something the owner wants to do himself/herself)?
Perhaps if tickets could be flagged by the owner as "help wanted" (or reassigned to a "help wanted" owner)? If this is possible, maybe the "looking for help" wiki pages could simply provide a (automatically generated?) list of tickets that are marked this way, organized in some appropriate way (by project or whatever).
Neat idea! I would propose an extension, and add "Help offers" tickets to the system. Cheers Matias
Rene Rivera wrote:
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki?
Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this.
Where is it? Cheers! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki? Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this.
Where is it?
Hm, I know you know how to use trac. So I'm baffled by the question :-\ Best I can answer is to show you report 14 <http://svn.boost.org/trac/boost/report/14> (scroll to the quicbook section). -- -- 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:
Joel de Guzman wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
1) Can someone in the IBD tell me where I can put QuickBook TODO items in the Wiki? Irrespective of the response from Matias... We do have an issue tracking system ;-) There's even a quickbook component I added and made you the owner of, just for things like this. Where is it?
Hm, I know you know how to use trac. So I'm baffled by the question :-\ Best I can answer is to show you report 14 <http://svn.boost.org/trac/boost/report/14> (scroll to the quicbook section).
Jeez, I looked at that and at first didn't see it. Maybe because I was suspicious with the "Active Tickets by Library / Component" title. Thanks! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
on Fri Jul 27 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
My feeling is that developer-centric documentation should move to the Trac Wiki, where it can be easily modified/updated by all of our developers.
Hm, I don't think editing the new website is any harder to modify/update. I worked hard to come up with a structure that makes it easy. All it takes is the svn access and a text editor. Or if editing XHTML directly is dreadful to you, there are many "visual" editors out there that will work.
It's harder for me. Once I have a login for Trac, I don't need to do any source control shenanigans, learn the XHTML conventions, and I don't need to find a visual editor. Editing a wiki page is very immediate. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On 7/27/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Doug Gregor wrote:
Account requests should go to all of the moderators at boost-owner@lists.boost.org.
* Various developer and release-manager documentation talks about Boost's CVS, but should now refer to Subversion. Better yet: migrate this documentation over to the Boost Trac, where it is easier to maintain and update, and won't be a part of the Boost distribution
May I suggest that people also consider migrating documentation to the beta website. Or if you don't feel like directly doing that you can:
* Add a page to the wiki with the docs. * Add a ticket to Trac pointing out the wiki page, and requesting to move the content to the beta website (making sure the component is set to "website").
That way I, or maybe one of the Doc Project people, can move/clone it.
I think we can cope with it at IBD. We will add it as a subproject. King Regards Matias
on Fri Jul 27 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Doug Gregor wrote:
Account requests should go to all of the moderators at boost-owner@lists.boost.org.
Here's an additional plea to get accounts ASAP. I've been adding components and corresponding owners to Trac. And the one thing holding up having a full set of components is not having people to assign them to.
You can create the components with no owner, then when people get accounts, delete and re-create the components with an owner. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Fri Jul 27 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Doug Gregor wrote:
Account requests should go to all of the moderators at boost-owner@lists.boost.org. Here's an additional plea to get accounts ASAP. I've been adding components and corresponding owners to Trac. And the one thing holding up having a full set of components is not having people to assign them to.
You can create the components with no owner, then when people get accounts, delete and re-create the components with an owner.
There's no way to not select an owner when adding components. It may have been possible in the past, but it's not possible now. -- -- 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
Doug Gregor wrote: One particularly
important bit: using svnmerge.py to simplify the handling of release branches.
Have you seen this: http://www.orcaware.com/svn/wiki/Svnmerge.py
Doug Gregor wrote:
=== Timeline === At 8:00 AM EDT on Tuesday, July 31, we will be cutting off access to the current Boost CVS repository. The Boost Subversion repository, mailing list archives, Boost Trac, beta.boost.org, and anything else hosted at OSL will also be unavailable during this time. === What you should do === If you have any outstanding changes to Boost in your local CVS tree, commit them before 8:00am EDT on Tuesday. Any changes to your local CVS tree that have not been committed to CVS will be lost and will have to manually be moved over Subversion. The Boost CVS repository will not be reopened.
Does this refer to the whole CVS tree - HEAD and release branches? I would think we want to create the Subversion tree with RC 1_34_1 - the latest release. And initiate the policy of creating changes on branches. The simplest? way to do this would be to make the subversion tree and check in the current release. Leave the CVS tree available for a while - at least for checkouts. Each developer can move his changes from CVS HEAD to his local CVS Tree, copy them to his local Subverison tree and then check them in on the appropriate library development branch. Robert Ramey
On Jul 27, 2007, at 3:59 PM, Robert Ramey wrote:
Doug Gregor wrote:
=== Timeline === At 8:00 AM EDT on Tuesday, July 31, we will be cutting off access to the current Boost CVS repository. The Boost Subversion repository, mailing list archives, Boost Trac, beta.boost.org, and anything else hosted at OSL will also be unavailable during this time. === What you should do === If you have any outstanding changes to Boost in your local CVS tree, commit them before 8:00am EDT on Tuesday. Any changes to your local CVS tree that have not been committed to CVS will be lost and will have to manually be moved over Subversion. The Boost CVS repository will not be reopened.
Does this refer to the whole CVS tree - HEAD and release branches?
Yes, the entire CVS repository will be migrated to Subversion.
I would think we want to create the Subversion tree with RC 1_34_1 - the latest release. And initiate the policy of creating changes on branches. The simplest? way to do this would be to make the subversion tree and check in the current release. Leave the CVS tree available for a while - at least for checkouts. Each developer can move his changes from CVS HEAD to his local CVS Tree, copy them to his local Subverison tree and then check them in on the appropriate library development branch.
No. The only way to make this change properly is to migrate everything to Subversion in one big step, then move forward from there. Having two repositories available is a recipe for confusion. - Doug
participants (10)
-
David Abrahams -
Doug Gregor -
Douglas Gregor -
eg -
Joel de Guzman -
Matias Capeletto -
Paul A Bristow -
Rene Rivera -
Robert Ramey -
Stjepan Rajko