Live read-only GIT mirrors of Boost trunk SVN
The live GIT mirrors of Boost trunk SVN have become a bit stale in recent months: https://github.com/ryppl/boost-svn, long time favourite of many, now 4 months stale. https://github.com/Beman/boost-trunk-git-svn is now 2 months stale. https://github.com/alexanderkjeldaas/boost-mirror is fresh, but has no branches nor tags. They all generally use git-svn, which tends to be brittle and not translate commits perfectly unfortunately e.g. SVN eol properties and other such metadata. So I decided to try out a new Subversion <=> Git mirroring tool, SubGit v2.0 EAP (http://subgit.com/eap/) whose author very kindly gave me a free open source licence and the result is at: https://github.com/ned14/boost-trunk All branches and tags, as far as I can tell, are mirrored correctly. I've set a cron job every 24 hours. Theoretically if we had an authors mapping file it would work in the opposite direction too i.e. be read-write. My next task is to live mirror a github repo into Boost Sandbox. Currently SubGit segfaults on this due to the complex SVN properties auto-translation which requires a specially marked up .gitattributes, but the author is very keen to fix the problem. In theory then it ought to just work. Any mistakes in my Boost mirror, or any problems, or even thoughts are gratefully received. Niall
[Please do not mail me a copy of your followup] boost@lists.boost.org spake the secret code <91F7C5E41BDB8741865487C9BDC9262B178CAD49@XMB116CNC.rim.net> thusly:
The live GIT mirrors of Boost trunk SVN have become a bit stale in recent months [...]
I tried making a mercurial mirror of the Boost trunk SVN and found that it took so long to do the conversion process, that I could never get it to complete on my home computer with cable modem internet access, but I could get it to complete on a shell account with faster trunk access. I also found the resulting repository was *huge* because I had *every* revision of boost ever recorded in the svn repository. I'm curious if you had different experiences when making a git repository. I am more familiar with mercurial than git, and I wanted to make a local mercurial repository so that I could work on my changes locally and checkpoint them using the version control system instead of manual backups. AFAIK, there's no way to record local changes with versioning using subversion, there's only committing to the remote server. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com
on Thu Apr 25 2013, Niall Douglas
The live GIT mirrors of Boost trunk SVN have become a bit stale in recent months:
https://github.com/ryppl/boost-svn, long time favourite of many, now 4 months stale.
https://github.com/Beman/boost-trunk-git-svn is now 2 months stale.
https://github.com/alexanderkjeldaas/boost-mirror is fresh, but has no branches nor tags.
They all generally use git-svn, which tends to be brittle and not translate commits perfectly unfortunately e.g. SVN eol properties and other such metadata. So I decided to try out a new Subversion <=> Git mirroring tool, SubGit v2.0 EAP (http://subgit.com/eap/) whose author very kindly gave me a free open source licence and the result is at:
https://github.com/ned14/boost-trunk
All branches and tags, as far as I can tell, are mirrored correctly. I've set a cron job every 24 hours. Theoretically if we had an authors mapping file it would work in the opposite direction too i.e. be read-write.
Nice. You can find a complete author mapping here: https://github.com/ryppl/Boost2Git/blob/master/authors.txt
My next task is to live mirror a github repo into Boost Sandbox. Currently SubGit segfaults on this due to the complex SVN properties auto-translation which requires a specially marked up .gitattributes, but the author is very keen to fix the problem. In theory then it ought to just work.
Any mistakes in my Boost mirror, or any problems, or even thoughts are gratefully received.
Don't put too much effort into this; Boost SVN->Git modularization is just about ready for review :-) -- Dave Abrahams
On 05/04/2013 03:30 AM, Dave Abrahams wrote:
on Thu Apr 25 2013, Niall Douglas
wrote: My next task is to live mirror a github repo into Boost Sandbox. Currently SubGit segfaults on this due to the complex SVN properties auto-translation which requires a specially marked up .gitattributes, but the author is very keen to fix the problem. In theory then it ought to just work.
Any mistakes in my Boost mirror, or any problems, or even thoughts are gratefully received. Don't put too much effort into this; Boost SVN->Git modularization is just about ready for review :-)
Dave, it would be great if the sandbox could be converted quickly, so GSoC students can use it ? It would be great if they didn't need to learn a thousand tools before being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. (For the time being I guess we could just use the boost sandbox repo via svn as in the past, yes ?) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Sat May 04 2013, Stefan Seefeld
On 05/04/2013 03:30 AM, Dave Abrahams wrote:
on Thu Apr 25 2013, Niall Douglas
wrote: My next task is to live mirror a github repo into Boost Sandbox. Currently SubGit segfaults on this due to the complex SVN properties auto-translation which requires a specially marked up .gitattributes, but the author is very keen to fix the problem. In theory then it ought to just work.
Any mistakes in my Boost mirror, or any problems, or even thoughts are gratefully received. Don't put too much effort into this; Boost SVN->Git modularization is just about ready for review :-)
Dave,
it would be great if the sandbox could be converted quickly, so GSoC students can use it ?
We don't expect anyone to commit to https://github.com/boostorg/sandbox once the transition is complete. In fact, it would be good to stop now. Instead, people should use individual Git repositories.
It would be great if they didn't need to learn a thousand tools before being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful.
I don't know what you mean here, sorry.
(For the time being I guess we could just use the boost sandbox repo via svn as in the past, yes ?)
I suggest you tell everyone to get him/herself set up at GitHub, and then you create one page with links to everyone's repositories. -- Dave Abrahams
On 05/04/2013 01:25 PM, Dave Abrahams wrote:
on Sat May 04 2013, Stefan Seefeld
wrote: it would be great if the sandbox could be converted quickly, so GSoC students can use it ? We don't expect anyone to commit to https://github.com/boostorg/sandbox once the transition is complete. In fact, it would be good to stop now. Instead, people should use individual Git repositories.
OK, that makes sense. So sanbox projects become entirely independent with the only dependency being some upstream boost version (which may correspond to either a release or a development version).
It would be great if they didn't need to learn a thousand tools before being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. I don't know what you mean here, sorry.
Never mind. I was thinking of a mix of versioning tools used for sandbox projects, boost trunk, etc., causing an unnecessarily steep learning curve. But if individual projects are to be hosted separately anyhow, that's much less of a concern (though it would still be useful to have clear and up-to-date guidelines for directory layout, build system, etc., to make it easier to merge to trunk should we ever get this far). Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Sat May 04 2013, Stefan Seefeld
It would be great if they didn't need to learn a thousand tools before being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. I don't know what you mean here, sorry.
Never mind. I was thinking of a mix of versioning tools used for sandbox projects, boost trunk, etc., causing an unnecessarily steep learning curve. But if individual projects are to be hosted separately anyhow, that's much less of a concern (though it would still be useful to have clear and up-to-date guidelines for directory layout, build system, etc., to make it easier to merge to trunk should we ever get this far).
Guidelines, OK. But, merge to trunk? Once the git transition is done, that'll be a non-issue. -- Dave Abrahams
participants (4)
-
Dave Abrahams -
legalize+jeeves＠mail.xmission.com -
Niall Douglas -
Stefan Seefeld