On Sun, Feb 13, 2011 at 9:54 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
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.
That might be interesting, but in SVN I don't know how to do the equivalent of Git local commits with occasional pushes to a public remote. I've been using that development model on other projects and have come to like it so much I've lost interest in SVN.
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.
I assumed, perhaps incorrectly, that since the boost/filesystem headers are replace with a symlink, that would cause trouble with 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).
Again, that's really a different experiment. Its basically simulating a distributed development environment with svn. The equivalent of "git push" is simulated with merge scripts. But I'm just not interested in trying to hang onto svn. I've come to like git much better. It gets in my way less often than svn. --Beman