On 2/13/2011 10:15 AM, Beman Dawes wrote:
The point of this public repo is to gain actual use experience with Git and with a modularized Boost library. Modularization followed the pattern ryppl is proposing - the top level directory is the same as the current SVN list/filesystem, with the addition an "include" directory with a "boost" sub-directory containing the current SVN boost/filesystem stuff. None of the existing filesystem content was changed.
I'm wondering if to make a more accurate comparison of the git experience vs. svn, it would be worthwhile to experiment with maintaining a modularized Boost Library directly in subversion.
So that the development environment will be identical to the current SVN trunk, I setup my local filesystem trunk repository using a little script:
svn export %BOOST_TRUNK% fs-trunk cd fs-trunk/libs rm -r filesystem git clone git@github.com:Beman/filesystem.git filesystem cd ..\boost del filesystem.hpp rm -r filesystem mklink filesystem.hpp ..\libs\filesystem\include\boost\filesystem.hpp mklink /d filesystem ..\libs\filesystem\include\boost\filesystem
The effect is to export the SVN trunk, then replace libs/filesystem with a git clone of the public repository. boost/filesystem is replaced with a symlink to libs\filesystem\include\boost\filesystem
Why export when you can overlay the svn version with the git version. And hence be able to do local commits with git. And then immediately commit to svn. And following on my comment about a modular lib in svn.. It might be convenient to put the modularized filesystem lib in svn. And then merge to the non-modular trunk (or release). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail