Git Modularization Ready for Review
Hi All, After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at http://github.com/boostorg http://bitbucket.org/boostorg or you can pull from these repositories and view them in your local browser. The conversion process is automated by http://jenkins.boost.org/job/Boost2Git/ using the tool at http://github.com/ryppl/Boost2Git The rules that describe how commits are distributed are in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt To understand how to edit that file, please read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though. -- Dave Abrahams
On Sat, May 4, 2013 at 3:08 PM, Dave Abrahams <dave@boostpro.com> wrote:
Hi All,
After substantial work, including massive changes by me and Daniel
See https://github.com/ryppl/Boost2Git/commits to get an idea of how big a job this was. The commit list is endless. Dave and Daniel deserve special thanks for carrying this project through!
Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
What is the story on branches and branch names? The Boost.System release branch is there, but https://github.com/boostorg/system shows 34 branches, and it looks like most of those are branches for other libraries that happened to include a Boost.System component. I suppose Git has a way to blow the unwanted branches away from the system repo? How close are we to being able to experiment with modular boost? Do we know what the updated https://svn.boost.org/trac/boost/wiki/TryModBoost instructions are? Many thanks, --Beman
on Sun May 05 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
What is the story on branches and branch names?
I think I need a more precise question in order to give a good answer, but I'll do my best. You can see the mapping of SVN paths to branch names in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt As mentioned in my previous posting, to understand the mapping, read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt It's important to note that in SVN, branches persist basically unobtrusively in history. If you don't explore the tree above /trunk/ and /branches/release/, you never see them. And even if you delete them in some later revision, you can still get to them by rewinding history. For example, there's nothing here: http://ci.boost.org/svn-trac/browser/branches/unordered but you can look back into history and there it is: http://ci.boost.org/svn-trac/browser/branches/unordered?rev=42181 By contrast, you may find Git branches somewhat obtrusive. However, the usual culture with Git is to delete feature branch references as soon as they are merged to some other branch. After all, the merged-to branch keeps the commit history alive and there's no longer any need to keep the old label around. If you delete a branch without merging it, of course, any commit history exclusively referenced by that branch is lost. Therefore we are conservative, preserving all SVN branches and tags as Git refs. If branche or tags were deleted in some SVN revision, they'll be converted to Git tags with the prefix "backups/" (see https://github.com/boostorg/system/tags for examples). Otherwise, as a rule, SVN paths below branches/ are converted to Git branches and SVN paths below tags/ are converted to Git tags, but of course you can control all that via the specific mappings in repositories.txt There are quite a few paths that are being mapped to a branch prefixed with "/old-branches/". I believe that pattern is a relic from earlier modularization efforts, and is not applied consistently. However, it is one good way of making some branches less obtrusive. We could decide to automatically put any SVN branch that hasn't been touched since revision XXXX under /old-branches/, for example.
The Boost.System release branch is there, but https://github.com/boostorg/system shows 34 branches, and it looks like most of those are branches for other libraries that happened to include a Boost.System component.
Yeah, quite a few branches seem to be empty in Boost.System, for example https://github.com/boostorg/system/commit/b59e42803ca7b37e2715657ba60532f988... We've made some effort to prevent the creation of empty branches, although it's difficult; clearly what we have isn't working in all cases. I'll see what I can do about it.
I suppose Git has a way to blow the unwanted branches away from the system repo?
Blowing away branches in Git is trivial, if a little obscure: git push <remote-name> :<branch-name>
How close are we to being able to experiment with modular boost? Do we know what the updated https://svn.boost.org/trac/boost/wiki/TryModBoost instructions are?
As long as the goal is to do it with the current build system, we still need to create the submodule references in https://github.com/boostorg/boost that point to all the libraries and tools. I'm working on that now. I think the instructions "should" be pretty close to correct once we've done that, but am not certain. Daniel? -- Dave Abrahams
On 6 May 2013 06:31, Dave Abrahams wrote:
I suppose Git has a way to blow the unwanted branches away from the system repo?
Blowing away branches in Git is trivial, if a little obscure:
git push <remote-name> :<branch-name>
Modern versions of Git also support this less obscure form: git push --delete <remote-name> <branch-name>
On Mon, May 6, 2013 at 1:31 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Sun May 05 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
What is the story on branches and branch names?
I think I need a more precise question in order to give a good answer, but I'll do my best. You can see the mapping of SVN paths to branch names in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt As mentioned in my previous posting, to understand the mapping, read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
One more precise question: Are we still planning to map trunk->develop and branches/release->master?
It's important to note that in SVN, branches persist basically unobtrusively in history. If you don't explore the tree above /trunk/ and /branches/release/, you never see them. And even if you delete them in some later revision, you can still get to them by rewinding history. For example, there's nothing here:
http://ci.boost.org/svn-trac/browser/branches/unordered
but you can look back into history and there it is:
http://ci.boost.org/svn-trac/browser/branches/unordered?rev=42181
By contrast, you may find Git branches somewhat obtrusive. However, the usual culture with Git is to delete feature branch references as soon as they are merged to some other branch. After all, the merged-to branch keeps the commit history alive and there's no longer any need to keep the old label around. If you delete a branch without merging it, of course, any commit history exclusively referenced by that branch is lost.
Thanks - that's helpful. I've added the last paragraph to https://svn.boost.org/trac/boost/wiki/StartModWorkflow
Therefore we are conservative, preserving all SVN branches and tags as Git refs. If branche or tags were deleted in some SVN revision, they'll be converted to Git tags with the prefix "backups/" (see https://github.com/boostorg/system/tags for examples). Otherwise, as a rule, SVN paths below branches/ are converted to Git branches and SVN paths below tags/ are converted to Git tags, but of course you can control all that via the specific mappings in repositories.txt
There are quite a few paths that are being mapped to a branch prefixed with "/old-branches/". I believe that pattern is a relic from earlier modularization efforts, and is not applied consistently. However, it is one good way of making some branches less obtrusive. We could decide to automatically put any SVN branch that hasn't been touched since revision XXXX under /old-branches/, for example.
That might be worth doing if it isn't too much work. Maybe XXXX could be the revision that corresponds to say one year ago, or maybe 18 months ago to be a bit more conservative.
The Boost.System release branch is there, but https://github.com/boostorg/system shows 34 branches, and it looks like most of those are branches for other libraries that happened to include a Boost.System component.
Yeah, quite a few branches seem to be empty in Boost.System, for example https://github.com/boostorg/system/commit/b59e42803ca7b37e2715657ba60532f988... We've made some effort to prevent the creation of empty branches, although it's difficult; clearly what we have isn't working in all cases. I'll see what I can do about it.
Seems like it would be helpful.
I suppose Git has a way to blow the unwanted branches away from the system repo?
Blowing away branches in Git is trivial, if a little obscure:
git push <remote-name> :<branch-name>
Good, and even easier with Jonathan's later suggestion. For a simple library like system, I'm only really interested in develop and master branches.
How close are we to being able to experiment with modular boost? Do we know what the updated https://svn.boost.org/trac/boost/wiki/TryModBoost instructions are?
As long as the goal is to do it with the current build system, we still need to create the submodule references in https://github.com/boostorg/boost that point to all the libraries and tools. I'm working on that now. I think the instructions "should" be pretty close to correct once we've done that, but am not certain. Daniel?
There was a tentative change to the current build system that would allow b2/bjam to handle the "cmake -P forward_headers.cmake" step. I don't know if that change was ever finalized. If not we will have to pester the Boost.Build folks to get it working. --Beman
on Mon May 06 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
On Mon, May 6, 2013 at 1:31 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Sun May 05 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
What is the story on branches and branch names?
I think I need a more precise question in order to give a good answer, but I'll do my best. You can see the mapping of SVN paths to branch names in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt As mentioned in my previous posting, to understand the mapping, read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
One more precise question: Are we still planning to map trunk->develop and branches/release->master?
Presently, as you can see, the mapping is trunk->master and branches/release->release. It could be easily changed, and I think that might be a very good idea because otherwise we have to do a bulk branch rename, which could cause havoc with developers. Daniel felt that the branch names should reflect the names we've used historically, but I think I disagree with him on that. I think there's too little benefit. Daniel, shall we argue? :-)
It's important to note that in SVN, branches persist basically unobtrusively in history. If you don't explore the tree above /trunk/ and /branches/release/, you never see them. And even if you delete them in some later revision, you can still get to them by rewinding history. For example, there's nothing here:
http://ci.boost.org/svn-trac/browser/branches/unordered
but you can look back into history and there it is:
http://ci.boost.org/svn-trac/browser/branches/unordered?rev=42181
By contrast, you may find Git branches somewhat obtrusive. However, the usual culture with Git is to delete feature branch references as soon as they are merged to some other branch. After all, the merged-to branch keeps the commit history alive and there's no longer any need to keep the old label around. If you delete a branch without merging it, of course, any commit history exclusively referenced by that branch is lost.
Thanks - that's helpful. I've added the last paragraph to https://svn.boost.org/trac/boost/wiki/StartModWorkflow
Therefore we are conservative, preserving all SVN branches and tags as Git refs. If branche or tags were deleted in some SVN revision, they'll be converted to Git tags with the prefix "backups/" (see https://github.com/boostorg/system/tags for examples). Otherwise, as a rule, SVN paths below branches/ are converted to Git branches and SVN paths below tags/ are converted to Git tags, but of course you can control all that via the specific mappings in repositories.txt
There are quite a few paths that are being mapped to a branch prefixed with "/old-branches/". I believe that pattern is a relic from earlier modularization efforts, and is not applied consistently. However, it is one good way of making some branches less obtrusive. We could decide to automatically put any SVN branch that hasn't been touched since revision XXXX under /old-branches/, for example.
That might be worth doing if it isn't too much work. Maybe XXXX could be the revision that corresponds to say one year ago, or maybe 18 months ago to be a bit more conservative.
I think it's probably doable. Another thing we might consider is mapping them to tags/old-branches/... These things are fairly easy to adjust.
The Boost.System release branch is there, but https://github.com/boostorg/system shows 34 branches, and it looks like most of those are branches for other libraries that happened to include a Boost.System component.
Yeah, quite a few branches seem to be empty in Boost.System, for example https://github.com/boostorg/system/commit/b59e42803ca7b37e2715657ba60532f988... We've made some effort to prevent the creation of empty branches, although it's difficult; clearly what we have isn't working in all cases. I'll see what I can do about it.
Seems like it would be helpful.
I suppose Git has a way to blow the unwanted branches away from the system repo?
Blowing away branches in Git is trivial, if a little obscure:
git push <remote-name> :<branch-name>
Good, and even easier with Jonathan's later suggestion.
For a simple library like system, I'm only really interested in develop and master branches.
Hopefully we'll be able to automatically prune the irrelevant ones, but if not, it's easy to write a script to prune everything but a set of specified branches. We can give that out to maintainers and they can make their own choices.
How close are we to being able to experiment with modular boost? Do we know what the updated https://svn.boost.org/trac/boost/wiki/TryModBoost instructions are?
As long as the goal is to do it with the current build system, we still need to create the submodule references in https://github.com/boostorg/boost that point to all the libraries and tools. I'm working on that now. I think the instructions "should" be pretty close to correct once we've done that, but am not certain. Daniel?
There was a tentative change to the current build system that would allow b2/bjam to handle the "cmake -P forward_headers.cmake" step. I don't know if that change was ever finalized. If not we will have to pester the Boost.Build folks to get it working.
I don't know either. -- Dave Abrahams
On Tue, May 7, 2013 at 12:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon May 06 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
...
One more precise question: Are we still planning to map trunk->develop and branches/release->master?
Presently, as you can see, the mapping is trunk->master and branches/release->release. It could be easily changed, and I think that might be a very good idea because otherwise we have to do a bulk branch rename, which could cause havoc with developers.
Strongly agree. We had previously agree to follow the Git Flow conventions, and so map trunk -> develop and branches/release -> master. It doesn't matter that the current mapping can be easily changed - the conversion isn't ready for prime time until that is done. OTOH, I'm not so worried about having some extra branches. It seems reasonable to ask developers to clean out unwanted branches. If you can clean out the empty ones, fine. Likewise for branches that have seen no activity for years. But I wouldn't want to delay the conversion waiting for such niceties. --Beman
2013/5/8 Beman Dawes <bdawes@acm.org>
On Tue, May 7, 2013 at 12:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon May 06 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
...
One more precise question: Are we still planning to map trunk->develop and branches/release->master?
Presently, as you can see, the mapping is trunk->master and branches/release->release. It could be easily changed, and I think that might be a very good idea because otherwise we have to do a bulk branch rename, which could cause havoc with developers.
Strongly agree.
We had previously agree to follow the Git Flow conventions, and so map trunk -> develop and branches/release -> master. It doesn't matter that the current mapping can be easily changed - the conversion isn't ready for prime time until that is done.
I am not opposed to master/develop. In fact, I am much in favor for Git Flow. The concern that I have with our current "release" branch is that it does not correspond to "master" in the Git Flow model. In Git Flow, you create a temporary release branch for stabilization. When the stabilization is completed, you 1. merge to "master", 2. merge to "develop", 3. create a tag, and 4. drop the release branch. In the end, "master" is stable at any point in time. However, in SVN we currently use "release" as "release preparation" or stabilization. This branch was not always guaranteed to be stable back in history. If we want to have a branch that corresponds to "master" in Git Flow, we need to artificially recreate it based on the tags. This is certainly not impossible, but requires further work. -- Daniel OTOH, I'm not so worried about having some extra branches. It seems
reasonable to ask developers to clean out unwanted branches. If you can clean out the empty ones, fine. Likewise for branches that have seen no activity for years. But I wouldn't want to delay the conversion waiting for such niceties.
--Beman
On Wed, May 8, 2013 at 7:00 PM, Daniel James <daniel@calamity.org.uk> wrote:
On 6 May 2013 16:32, Beman Dawes <bdawes@acm.org> wrote:
One more precise question: Are we still planning to map trunk->develop and branches/release->master?
I'd hope not, the useful history is in trunk.
IIUC, It is really just a renaming, so the history is still there. If you do a log on develop you will see all the history from what used to be called trunk. Part of why I consider the mapping (or, if you prefer, renaming) to be so important is that we need to verify that the history follows along and is not disrupted. --Beman
On 9 May 2013 02:54, Beman Dawes <bdawes@acm.org> wrote:
IIUC, It is really just a renaming, so the history is still there. If you do a log on develop you will see all the history from what used to be called trunk.
The problem is that if someone checks out a repo and run git annotate or bisect, then it's quite likely they'll just find changes with the title 'Merge to release' with lots of changes merged together. Which is not very helpful.
Part of why I consider the mapping (or, if you prefer, renaming) to be so important is that we need to verify that the history follows along and is not disrupted.
Can't we design a release system so that the current release branch is labelled with something like 'svn-release' or just 'release' and that it used until a developer tags/branches for a new release? I don't know how it's planned to work, but I expect that's feasible.
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
This is great news! Please allow me to suggest http://windows.github.com/ here, a very easy way to use git on windows. Best regards, Saurav
Le 04/05/13 21:08, Dave Abrahams a écrit :
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
The conversion process is automated by http://jenkins.boost.org/job/Boost2Git/ using the tool at http://github.com/ryppl/Boost2Git
The rules that describe how commits are distributed are in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt
To understand how to edit that file, please read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
Now that the it is ready for review, could you point where is the documentation to review? Could I move the following from repository thread to core? "boost/detail/atomic_redef_macros.hpp" : "include/boost/detail/atomic_redef_macros.hpp"; "boost/detail/atomic_undef_macros.hpp" : "include/boost/detail/atomic_undef_macros.hpp"; I added these files. They are used now by Boost.Thread, but it should be used by SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and https://svn.boost.org/trac/boost/ticket/6843). Best, Vicente Best, Vicente
on Sun May 05 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 04/05/13 21:08, Dave Abrahams a écrit :
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
The conversion process is automated by http://jenkins.boost.org/job/Boost2Git/ using the tool at http://github.com/ryppl/Boost2Git
The rules that describe how commits are distributed are in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt
To understand how to edit that file, please read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
Now that the it is ready for review, could you point where is the documentation to review?
Sorry, what documentation?
Could I move the following from repository thread to core?
"boost/detail/atomic_redef_macros.hpp" : "include/boost/detail/atomic_redef_macros.hpp"; "boost/detail/atomic_undef_macros.hpp" : "include/boost/detail/atomic_undef_macros.hpp"; I added these files. They are used now by Boost.Thread, but it should be used by SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and https://svn.boost.org/trac/boost/ticket/6843). Best, Vicente
First, are you sure they don't belong in their own module? It might be a good idea to minimize the size of the core "blob." Second, sure, we can do that. Please try editing the ruleset yourself and submitting a pull request as described above. We need to find out if our instructions are adequate. Thanks, -- Dave Abrahams
On Mon, May 6, 2013 at 1:34 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Sun May 05 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote: ...
Now that the it is ready for review, could you point where is the documentation to review?
Sorry, what documentation?
Perhaps Vicente is referring to the documentation in the "Git and Modular Boost" section of https://svn.boost.org/trac/boost/ If so, that's mostly my responsibility and I'll start updating it as needed to reflect the full history now available. --Beman
Le 06/05/13 07:34, Dave Abrahams a écrit :
on Sun May 05 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 04/05/13 21:08, Dave Abrahams a écrit :
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
The conversion process is automated by http://jenkins.boost.org/job/Boost2Git/ using the tool at http://github.com/ryppl/Boost2Git
The rules that describe how commits are distributed are in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt
To understand how to edit that file, please read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
Now that the it is ready for review, could you point where is the documentation to review? Sorry, what documentation? What is ready for review then, the split on modules?
Could I move the following from repository thread to core?
"boost/detail/atomic_redef_macros.hpp" : "include/boost/detail/atomic_redef_macros.hpp"; "boost/detail/atomic_undef_macros.hpp" : "include/boost/detail/atomic_undef_macros.hpp"; I added these files. They are used now by Boost.Thread, but it should be used by SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and https://svn.boost.org/trac/boost/ticket/6843). Best, Vicente First, are you sure they don't belong in their own module? It might be a good idea to minimize the size of the core "blob." Where this kind of workarounds should go, Boost.Config?
Second, sure, we can do that. Please try editing the ruleset yourself and submitting a pull request as described above. We need to find out if our instructions are adequate.
I'm not sure I know how this must be done :( Anyway, I will try. Vicente
on Mon May 06 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 06/05/13 07:34, Dave Abrahams a écrit :
on Sun May 05 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 04/05/13 21:08, Dave Abrahams a écrit :
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
The conversion process is automated by http://jenkins.boost.org/job/Boost2Git/ using the tool at http://github.com/ryppl/Boost2Git
The rules that describe how commits are distributed are in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt
To understand how to edit that file, please read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
Now that the it is ready for review, could you point where is the documentation to review? Sorry, what documentation?
What is ready for review then, the split on modules?
The way the modules are being split up, and the resulting Git histories.
Could I move the following from repository thread to core?
"boost/detail/atomic_redef_macros.hpp" : "include/boost/detail/atomic_redef_macros.hpp"; "boost/detail/atomic_undef_macros.hpp" : "include/boost/detail/atomic_undef_macros.hpp"; I added these files. They are used now by Boost.Thread, but it should be used by SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and https://svn.boost.org/trac/boost/ticket/6843). Best, Vicente First, are you sure they don't belong in their own module? It might be a good idea to minimize the size of the core "blob." Where this kind of workarounds should go, Boost.Config?
Oh, I didn't realize they were just workarounds. Perhaps core would be best.
Second, sure, we can do that. Please try editing the ruleset yourself and submitting a pull request as described above. We need to find out if our instructions are adequate.
I'm not sure I know how this must be done :(
There's only one way to find out!
Anyway, I will try.
Thanks! -- Dave Abrahams
Looking forward to getting this working fully. Are there changes to the regression script tools that would let the regression tests run against the git repos? Have they been run already? Tom
Dave, any idea what happened to the sandbox "module" ? It appears to be empty (even though it is pretty big, i.e. contains a lot of history). Coincidentally, `git log` reports the last commit in 2003. What happened to the rest ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
https://github.com/boostorg/sandbox/tree/trunk HTH Sent from my moss-covered three-handled family gradunza On May 7, 2013, at 6:25 PM, Stefan Seefeld <stefan@seefeld.name> wrote:
Dave,
any idea what happened to the sandbox "module" ? It appears to be empty (even though it is pretty big, i.e. contains a lot of history). Coincidentally, `git log` reports the last commit in 2003. What happened to the rest ?
Thanks, Stefan
--
...ich hab' noch einen Koffer in Berlin...
Wouldn't it be better if trunk was set as the main branch of the sandbox repository to avoid confusion ? On Wed, May 8, 2013 at 4:58 AM, Dave Abrahams <dave@boostpro.com> wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH
Sent from my moss-covered three-handled family gradunza
BR
Matus
on Tue May 07 2013, Matus Chochlik <chochlik-AT-gmail.com> wrote:
Wouldn't it be better if trunk was set as the main branch of the sandbox repository to avoid confusion ?
Done.
On Wed, May 8, 2013 at 4:58 AM, Dave Abrahams <dave@boostpro.com> wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH
Sent from my moss-covered three-handled family gradunza
BR
Matus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams
On 08 May 2013 03:59 Dave Abrahams [mailto:dave@boostpro.com] wrote :
Sent from my moss-covered three-handled family gradunza
By a process of "Calculatus Eliminatus"[1] I suspect a MacGuffin[2] driving the plot forwards to the goal of modularisation. If it was just a nice tag line in protest to all the "sent from my iphone" it certainly made me laugh Alex [1] http://en.wikipedia.org/wiki/The_Cat_in_the_Hat_(TV_special) [2] http://en.wikipedia.org/wiki/MacGuffin
On 05/07/2013 10:58 PM, Dave Abrahams wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH
Thanks ! Now I can indeed see some content in the web browser. However, the suggested URL for cloning is sill displayed to be https://github.com/boostorg/sandbox.git, which I used yesterday with `git clone <url>`, which results in an empty directory. Something seems wrong there... Thanks for all your effort ! Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Wed, May 8, 2013 at 1:13 PM, Stefan Seefeld <stefan@seefeld.name> wrote:
On 05/07/2013 10:58 PM, Dave Abrahams wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH
Thanks ! Now I can indeed see some content in the web browser. However, the suggested URL for cloning is sill displayed to be https://github.com/boostorg/sandbox.git, which I used yesterday with `git clone <url>`, which results in an empty directory. Something seems wrong there...
You need to do 'git checkout trunk' Matus
On 05/08/2013 07:35 AM, Matus Chochlik wrote:
On Wed, May 8, 2013 at 1:13 PM, Stefan Seefeld <stefan@seefeld.name> wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH Thanks ! Now I can indeed see some content in the web browser. However,
On 05/07/2013 10:58 PM, Dave Abrahams wrote: the suggested URL for cloning is sill displayed to be https://github.com/boostorg/sandbox.git, which I used yesterday with `git clone <url>`, which results in an empty directory. Something seems wrong there...
You need to do 'git checkout trunk'
Ah, indeed I do. It seems the normal 'git clone' call checks out the 'master' branch by default, but since this sandbox doesn't have one under that name, I had to check out explicitly. Now all looks good. Anyhow, this is just for archeology, as it was suggested we use the (original) sandbox read-only, and develop / maintain individual projects elsewhere. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Wed May 08 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote:
On 05/07/2013 10:58 PM, Dave Abrahams wrote:
https://github.com/boostorg/sandbox/tree/trunk
HTH
Thanks ! Now I can indeed see some content in the web browser. However, the suggested URL for cloning is sill displayed to be https://github.com/boostorg/sandbox.git, which I used yesterday with `git clone <url>`, which results in an empty directory. Something seems wrong there...
Thanks for all your effort !
OK, fixed. -- Dave Abrahams
Hi Dave, On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion. The repository at https://github.com/boostorg/build contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources. The original idee from Volodya was to completely remove the "v2" subdirectory and put everything current in "tools/build/v2/" in the toplevel directory. I would expect the contents of "tools/build/v2/" in the toplevel directory, especially the c sources in their new location "engine". I have scanned the conversion rules but can not find the relocation information. Can you please take a look at this as this seems gone wrong somehow? The other idea would be to keep the "v2" directory for now and move everything thing up vai git after the conversion. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/build
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning. The original idee from Volodya was to completely remove the "v2"
subdirectory and put everything current in "tools/build/v2/" in the toplevel directory. I would expect the contents of "tools/build/v2/" in the toplevel directory, especially the c sources in their new location "engine".
Yes, I remember.
I have scanned the conversion rules but can not find the relocation information. Can you please take a look at this as this seems gone wrong somehow?
Probably. We wanted to make sure that no commit is lost.
The other idea would be to keep the "v2" directory for now and move everything thing up vai git after the conversion.
Another option would be to create a second repository "build2".
Yours,
Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/build
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning.
It looks better now, but the root of the repo has 'build', which has 'v2', which has actual content. Can we actually have content of 'v2' at the top level? - Volodya
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: Friday, May 17, 2013 4:08 PM To: boost@lists.boost.org Subject: Re: [boost] Git Modularization Ready for Review
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I've looked at https://github.com/boostorg/math/tree/master/doc - where we have some recent commits from John and me. Until I tried the history button they appear in alphabetical folder order which isn't so useful. They seem to be there OK . This sounds quite an achievement. Keep up the Good Work Paul PS I note that (purely out of conceit of course ;-) I clicked on my name and it shows my Open Source contributions - but only those outside Boost.Math - a miserable 6 in total, and no reference to Boost.Math. That is a bit disappointing as I was hoping it would show I was a Jolly Good Chap! But that's trivia... --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 17 May 2013 18:00, Paul A. Bristow wrote:
I've looked at https://github.com/boostorg/math/tree/master/doc - where we have some recent commits from John and me.
Until I tried the history button they appear in alphabetical folder order which isn't so useful.
That's the Files view, showing the directory contents not the commits, so it's showing the files in alphabetical order. It happens to show the most recent commit to each file/dir on the right, but it's not the best way to look at commits. Either use the history button or switch to the Commits tab, above.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Wakely Sent: Friday, May 17, 2013 6:11 PM To: boost@lists.boost.org Subject: Re: [boost] Git Modularization Ready for Review
On 17 May 2013 18:00, Paul A. Bristow wrote:
I've looked at https://github.com/boostorg/math/tree/master/doc - where we have some recent
commits from John and me.
Until I tried the history button they appear in alphabetical folder order which isn't so useful.
That's the Files view, showing the directory contents not the commits, so it's showing the files in alphabetical order. It happens to show the most recent commit to each file/dir on the right, but it's not the best way to look at commits. Either use the history button or switch to the Commits tab, above.
Thanks. As you will gather, I'm a GIT newbie in fumble mode :-( Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
2013/5/17 Vladimir Prus <ghost@cs.msu.su>
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/**build <https://github.com/boostorg/build>
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning.
It looks better now, but the root of the repo has 'build', which has 'v2', which has actual content. Can we actually have content of 'v2' at the top level?
The current layout reflects what is in subversion. Both 'build' and 'jam' from the directory 'tools' are placed in the repository 'build'. 'jam' has been deleted somewhere in the history, so only 'build' remains. If we simply use 'tools/build/v2' as the top level of the repository 'build', where shall we place the parts of Boost.Build's history that does not match that path?
On 18.05.2013 00:49, Daniel Pfeifer wrote:
2013/5/17 Vladimir Prus <ghost@cs.msu.su>
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/**build <https://github.com/boostorg/build>
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning.
It looks better now, but the root of the repo has 'build', which has 'v2', which has actual content. Can we actually have content of 'v2' at the top level?
The current layout reflects what is in subversion. Both 'build' and 'jam' from the directory 'tools' are placed in the repository 'build'. 'jam' has been deleted somewhere in the history, so only 'build' remains.
If we simply use 'tools/build/v2' as the top level of the repository 'build', where shall we place the parts of Boost.Build's history that does not match that path?
I would be fine with /dev/null, to be honest, unless Rene and Steven have any concerns. That is part of the history that is either not used at all, or has been rewritten over and over, so it won't be much useful in future. - Volodya
on Fri May 17 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 18.05.2013 00:49, Daniel Pfeifer wrote:
2013/5/17 Vladimir Prus <ghost@cs.msu.su>
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/**build <https://github.com/boostorg/build>
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning.
It looks better now, but the root of the repo has 'build', which has 'v2', which has actual content. Can we actually have content of 'v2' at the top level?
The current layout reflects what is in subversion. Both 'build' and 'jam' from the directory 'tools' are placed in the repository 'build'. 'jam' has been deleted somewhere in the history, so only 'build' remains.
If we simply use 'tools/build/v2' as the top level of the repository 'build', where shall we place the parts of Boost.Build's history that does not match that path?
I would be fine with /dev/null, to be honest, unless Rene and Steven have any concerns. That is part of the history that is either not used at all, or has been rewritten over and over, so it won't be much useful in future.
You're free to delete any branches you want after the conversion is over (it's really easy), but until then, we want to make sure every commit is accounted for. Any commits that aren't caught by the ruleset end up in https://github.com/boostorg/svn2git-fallback and the build at http://jenkins.boost.org fails. You can make an arbitrarily obscure branch name (e.g. old-branches/deleteme) and send unwanted history there, if you like. Please try to submit a pull request with edits to repositories.txt. An explanation of the semantics is at: https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt -- Dave Abrahams
On 20.05.2013 10:08, Dave Abrahams wrote:
I would be fine with /dev/null, to be honest, unless Rene and Steven have any concerns. That is part of the history that is either not used at all, or has been rewritten over and over, so it won't be much useful in future.
You're free to delete any branches you want after the conversion is over (it's really easy), but until then, we want to make sure every commit is accounted for. Any commits that aren't caught by the ruleset end up in https://github.com/boostorg/svn2git-fallback and the build at http://jenkins.boost.org fails.
You can make an arbitrarily obscure branch name (e.g. old-branches/deleteme) and send unwanted history there, if you like. Please try to submit a pull request with edits to repositories.txt. An explanation of the semantics is at: https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Dave, I have spent around 30 minutes trying to grok this format, and I cannot quite figure how how to sent tools/build/v2 directory to master branch of "build" repo, while sending everything else from trunk/tools/build into some other branch. If the change is easy, as you make it sound, can either you or Daniel make it? Thanks, Volodya
on Tue May 21 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 20.05.2013 10:08, Dave Abrahams wrote:
I would be fine with /dev/null, to be honest, unless Rene and Steven have any concerns. That is part of the history that is either not used at all, or has been rewritten over and over, so it won't be much useful in future.
You're free to delete any branches you want after the conversion is over (it's really easy), but until then, we want to make sure every commit is accounted for. Any commits that aren't caught by the ruleset end up in https://github.com/boostorg/svn2git-fallback and the build at http://jenkins.boost.org fails.
You can make an arbitrarily obscure branch name (e.g. old-branches/deleteme) and send unwanted history there, if you like. Please try to submit a pull request with edits to repositories.txt. An explanation of the semantics is at: https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Dave,
I have spent around 30 minutes trying to grok this format, and I cannot quite figure how how to sent tools/build/v2 directory to master branch of "build" repo, while sending everything else from trunk/tools/build into some other branch.
That doesn't sound like a very accurate reflection of history. There used to be code in tools/build/, directly. What "other branch" should that go into, and at what path would you like it to be placed? And there are lots of changes outside trunk/ that should get similar treatment, whatever you decide to do. See: https://github.com/boostorg/build/branches https://github.com/boostorg/build/tags One possibility is that you keep everything under tools/build (other than tools/build/v2) in the branches where it currently resides, but put it in a subdirectory called v1/ rather than at the top level. However, there's probably a point in history where that stuff would *belong* at the top level because, e.g., v2 didn't exist.
If the change is easy, as you make it sound, can either you or Daniel make it?
We could... but I am a little concerned about making changes to history that diverge too far from reality. Remember, you are free to move things around and rename branches after modularization is complete... but I'm not sure we should do too much revision of the actual history. Thoughts? -- Dave Abrahams
on Fri May 17 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 14.05.2013 19:13, Daniel Pfeifer wrote:
2013/5/13 Jürgen Hunold <jhunold@gmx.eu>
Hi Dave,
On Saturday, 4. May 2013 12:08:22 Dave Abrahams wrote:
Hi All,
After substantial work, including massive changes by me and Daniel Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository.
Thanks for the work. Having done CVS -> svn myself, I really appreciate this.
You can view the results at
I have some questions concerning the Boost.Build conversion.
The repository at
https://github.com/boostorg/build
contains a "buildv2" directory containing the Boost.Build .jam files and "jamsrc" directory containing the c sources.
It seems the path seperators got lost. I think I fixed that problem, the conversion is currently rerunning.
It looks better now, but the root of the repo has 'build', which has 'v2', which has actual content. Can we actually have content of 'v2' at the top level?
We could, but that leaves open some questions: 1. What does history look like? At some point, there's the v1 code at the top level. Decide how you want those branches and commits distributed, and we can set it up. 2. Will this break scripts and other tools that invoke bjam? -- Dave Abrahams
On Sat, May 4, 2013 at 11:08 PM, Dave Abrahams <dave@boostpro.com> wrote:
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
I'm not sure if this is a problem and should be fixed, but Boost.Log currently uses some configuration projects that reside in Boost.Context (while Boost.Context itself is not used). Basically, libs/log/build/log-architecture.jam uses /boost/architecture//* projects that happen to reside in libs/context/config. I know, hijacking configure projects like that may not be a good thing but it seemed better than duplicating them in Boost.Log. Also, /boost/architecture//* doesn't imply any relation to Boost.Context in the first place. Additionally, I have a few configure projects of my own in libs/log/config that might be useful for other libraries. So, what I'm asking is: 1. Will this work after modulatization? Does it mean that Boost.Log will not compile without Boost.Context? 2. Maybe it's worth to move all such configure projects to some common place accessible to all libraries? What that place could be?
On Wed, May 15, 2013 at 11:59 PM, Andrey Semashev <andrey.semashev@gmail.com
wrote:
On Sat, May 4, 2013 at 11:08 PM, Dave Abrahams <dave@boostpro.com> wrote:
Daniel and I are ready to accept your feedback on the results of modularization, and especially your pull requests containing edits to the ruleset. I will the steering committee to establish a formal review period, though.
I'm not sure if this is a problem and should be fixed, but Boost.Log currently uses some configuration projects that reside in Boost.Context (while Boost.Context itself is not used). Basically, libs/log/build/log-architecture.jam uses /boost/architecture//* projects that happen to reside in libs/context/config. I know, hijacking configure projects like that may not be a good thing but it seemed better than duplicating them in Boost.Log. Also, /boost/architecture//* doesn't imply any relation to Boost.Context in the first place. Additionally, I have a few configure projects of my own in libs/log/config that might be useful for other libraries.
So, what I'm asking is:
1. Will this work after modulatization? Does it mean that Boost.Log will not compile without Boost.Context? 2. Maybe it's worth to move all such configure projects to some common place accessible to all libraries? What that place could be?
Ping? Any opinions on this?
participants (16)
-
Alex Perry -
Andrey Semashev -
Beman Dawes -
Daniel James -
Daniel Pfeifer -
Dave Abrahams -
Jonathan Wakely -
Jürgen Hunold -
Klaim - Joël Lamotte -
Matus Chochlik -
Paul A. Bristow -
Saurav -
Stefan Seefeld -
Tom Kent -
Vicente J. Botet Escriba -
Vladimir Prus