Re: [boost] [Git] Boost Filesystem now has public GitHub repository

Subject: Re: [boost] [Git] Boost Filesystem now has public GitHub repository
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-02-14 06:59:14

On Sun, Feb 13, 2011 at 9:54 PM, Rene Rivera <grafikrobot_at_[hidden]> 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_at_[hidden]: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