[Git] Boost Filesystem now has public GitHub repository
I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub. See https://github.com/Beman/filesystem 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. 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 Note that no changes whatsoever needed to be made to either my Visual Studio or Boost.Build setups, Jamfiles, or anything else. Everything just works. The setup is a pleasure to use. I commit changes locally whenever it makes sense, without any need to maintain stability. Then when work reaches a stable state, I push it out to GitHub. When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request. So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile. --Beman
On 13/02/11 17:15, Beman Dawes wrote:
I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub.
So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile.
I am glad that somehow stepped upf or this. I am really happy it worked out so well. can't this process be used for a possible git boost migration ? seems easier that most solution already presented. it also has the advantage to not force git into someone's throat. Good job :)
On Sun, Feb 13, 2011 at 11:25 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
On 13/02/11 17:15, Beman Dawes wrote:
I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub.
So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile.
I am glad that somehow stepped upf or this. I am really happy it worked out so well. can't this process be used for a possible git boost migration ?
If a bunch of active libraries were to switch to this process well before Boost converted to Git, it would help ensure a smooth transition. But I glossed over feeding diffs back into the current SVN trunk. I need to smooth that out, probably by writing a little script. git-svn isn't useful because the Git repo has a different directory structure than the SVN repo. --Beman
On Feb 13, 2011, at 11:15 AM, Beman Dawes wrote:
I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub.
Excellent! I will create a Boost.Defrag module for your git repository.
Daniel Pfeifer: "On the boost-dev list, Dave suggested to "call this something else, that includes a reference to the word 'modularized' somehow, just to distinguish it from the several unmodularized boost-cmakes".
The term 'module' however, already has a meaning in the CMake context (as in 'Standard CMake Modules' in the CMake documentation). So I thought we might label the Boost components/modules as 'fragments'.
The Boost.Defrag project is used to put these fragments together, hence the name."
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.
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
This is almost exactly what I was proposing earlier, with the exception that your script would be handled by bjam.
Note that no changes whatsoever needed to be made to either my Visual Studio or Boost.Build setups, Jamfiles, or anything else. Everything just works.
The setup is a pleasure to use. I commit changes locally whenever it makes sense, without any need to maintain stability. Then when work reaches a stable state, I push it out to GitHub.
When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request.
So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile.
I am new to git (this week) and must say that I concur with your experience.
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Feb 13, 2011 at 11:41 AM, Daniel Larimer <dlarimer@gmail.com> wrote:
On Feb 13, 2011, at 11:15 AM, Beman Dawes wrote:
....>>
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
This is almost exactly what I was proposing earlier, with the exception that your script would be handled by bjam.
Since it only has to be done once, on initial setup, there didn't seem to be much motivation for anything other than a simple script. Thanks, --Beman
I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub.
See https://github.com/Beman/filesystem
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.
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
Note that no changes whatsoever needed to be made to either my Visual Studio or Boost.Build setups, Jamfiles, or anything else. Everything just works.
The setup is a pleasure to use. I commit changes locally whenever it makes sense, without any need to maintain stability. Then when work reaches a stable state, I push it out to GitHub.
When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request.
So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile.
Sure, as long as you deal with the git repository only, everything is fine. The problems start when you want to integrate your changes back into the Boost SVN repo, which is usually a plain PITA. Regards Hartmut --------------- http://boost-spirit.com
On Sun, Feb 13, 2011 at 12:37 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request.
So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile.
Sure, as long as you deal with the git repository only, everything is fine. The problems start when you want to integrate your changes back into the Boost SVN repo, which is usually a plain PITA.
Agreed, but I'll wrap the diff/patch sequence in a script to make it easy. Remember too that the point is to test Git and a modularized (or unified, or whatever you want to call it) directory structure. So it doesn't really matter that the last step is clunky; that's not what I'm trying to get experience with. --Beman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 13 Feb 2011 11:15:55 -0500 Beman Dawes <bdawes@acm.org> wrote:
The point of this public repo is to gain actual use experience with Git and with a modularized Boost library.
Oh boy. On Sun, 13 Feb 2011 11:15:55 -0500 Beman Dawes <bdawes@acm.org> wrote:
So far this whole experiment has been very reassuring. No problems and everything worked instantly.
How do you plan to get your changes back into Boost SVN, without loosing versioning information? The setup you've described looks incredibly painful. You've decided to completely forgo the use of developed cross-VCS tools in favor of applying patches locally? Why have VCS at all, then? The Spirit developers considered moving Spirit development outside of the Boost SVN. I was the person who did most of the research on the implementation of such a move. The extensive research I did into Git, Mercurial, BZR and downstream SVN mirrors all brought me to the same conclusion: that the sort of workflow you're describing is a PITA. On Sun, 13 Feb 2011 11:15:55 -0500 Beman Dawes <bdawes@acm.org> wrote:
When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing.
You mean, you are going to manually commit each git commit to svn (resulting in two commits for every actual revision)? Or are you just going to squash your git commits and apply them at once? On Sun, 13 Feb 2011 10:02:33 -0500 (EST) bdawes@acm.org wrote:
Author: bemandawes Date: 2011-02-13 10:02:27 EST (Sun, 13 Feb 2011) New Revision: 68837 URL: http://svn.boost.org/trac/boost/changeset/68837
Log: Merge changes from https://github.com/Beman/filesystem. Important changes include fix for serious Windows reparse point bug, code cleanup, reference doc fixes and addition of missing functions, and the addition of symlink_option for recursive_directory_iterator. Added: trunk/libs/filesystem/v3/test/msvc10/tut5/ trunk/libs/filesystem/v3/test/msvc10/tut5/tut5.vcxproj (contents, props changed) trunk/libs/filesystem/v3/test/msvc10/tut6a/ trunk/libs/filesystem/v3/test/msvc10/tut6a/tut6a.vcxproj (contents, props changed) trunk/libs/filesystem/v3/test/msvc10/tut6b/ trunk/libs/filesystem/v3/test/msvc10/tut6b/tut6b.vcxproj (contents, props changed) trunk/libs/filesystem/v3/test/msvc10/tut6c/ trunk/libs/filesystem/v3/test/msvc10/tut6c/tut6c.vcxproj (contents, props changed) Text files modified: trunk/boost/filesystem/v3/operations.hpp | 81 +++++++-- trunk/libs/filesystem/v3/doc/path_table.cpp | 2 trunk/libs/filesystem/v3/doc/reference.html | 260 +++++++++++++++++++++++--------- trunk/libs/filesystem/v3/src/operations.cpp | 25 ++ trunk/libs/filesystem/v3/test/msvc10/filesystem-v3.sln | 10 + trunk/libs/filesystem/v3/test/operations_test.cpp | 311 ++++++++++++++++++++++++++++----------- 6 files changed, 500 insertions(+), 189 deletions(-)
So you're just going to squash git commits and apply them at once :(? It is in bad form in the Boost world to commit multiple changes at once, as this makes it harder to track down breaking changes. It seems clear to me that this is a violation of our Boost SVN policies and culture. Where is the list discussion about this change? Commits should be made atomically. And you should not squash commits together - if there is a problem with a change you make, it becomes harder for others (or yourself) to revert it. This is a mistake that I myself have made in the past. Steven was reverting changes that I made to Boost.Config - other, valid changes to Boost configuration were also changed in the same commit. On Sun, 13 Feb 2011 09:48:03 -0500 (EST) bdawes@acm.org wrote:
Author: bemandawes Date: 2011-02-13 09:48:01 EST (Sun, 13 Feb 2011) New Revision: 68836 URL: http://svn.boost.org/trac/boost/changeset/68836
Log: Initial commit; bitmask.hpp is needed by upcoming filesystem changes Added: trunk/boost/detail/bitmask.hpp (contents, props changed)
Where is the list discussion about this speculative addition to the Boost detail headers? Why is this not in filesystem, if it is code that filesystem needs? - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1YJiIACgkQ9cB/V3/s9Ew2yACgiVouBjfCfwIRFnBMy/K+ZN0I szkAoKdDFv/73DdfJHRICsOXNLd2eLuC =rzq2 -----END PGP SIGNATURE-----
AMDG On 2/13/2011 10:42 AM, Bryce Lelbach (wash) wrote:
So you're just going to squash git commits and apply them at once :(? It is in bad form in the Boost world to commit multiple changes at once, as this makes it harder to track down breaking changes.
It seems clear to me that this is a violation of our Boost SVN policies and culture. Where is the list discussion about this change?
It's Beman's library, so he's free to manage it in any way he wants as long as it doesn't go against the release process.
Commits should be made atomically. And you should not squash commits together - if there is a problem with a change you make, it becomes harder for others (or yourself) to revert it.
Yes, but... If there's a problem, then Beman gets to fix it. If he's willing to deal with this, then I don't have a problem with it.
This is a mistake that I myself have made in the past. Steven was reverting changes that I made to Boost.Config - other, valid changes to Boost configuration were also changed in the same commit.
In Christ, Steven Watanabe
On Sun, Feb 13, 2011 at 1:42 PM, Bryce Lelbach <admin@thefireflyproject.us> wrote:
Beman Dawes <bdawes@acm.org> wrote:
So far this whole experiment has been very reassuring. No problems and everything worked instantly.
How do you plan to get your changes back into Boost SVN, without loosing versioning information? The setup you've described looks incredibly painful.
It would be, except that it will be scripted so it is just typing the name of a single command. But who cares? The point is to evaluate Git and a new unified directory structure, It doesn't matter if the round-tripping takes an extra step. That's just temporary.
You've decided to completely forgo the use of developed cross-VCS tools in favor of applying patches locally? Why have VCS at all, then?
Changing to Git and changing the Boost directory structure to support modularization are really big changes. There is no way I'm going to accept such changes without trying them first. I don't want to wait until Ryppl is done, only to find the version control system or directory structure required won't work with my development style.
The Spirit developers considered moving Spirit development outside of the Boost SVN. I was the person who did most of the research on the implementation of such a move. The extensive research I did into Git, Mercurial, BZR and downstream SVN mirrors all brought me to the same conclusion: that the sort of workflow you're describing is a PITA.
So what? It is just a test involving one library. The upside is that it allows us to say with the assurance that comes from having actually used it that an approach does work in practice.
On Sun, 13 Feb 2011 11:15:55 -0500 Beman Dawes <bdawes@acm.org> wrote:
When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing.
You mean, you are going to manually commit each git commit to svn (resulting in two commits for every actual revision)? Or are you just going to squash your git commits and apply them at once?
Depends on what is changing, and whether or not I want to squash a set of commits. I'm doing this locally now, by the way, and have do so for years. I like to commit changes that I know to be unstable, but don't want to destabilize trunk. So I use a very clunky combination of backups and a local SVN repo to achieve the effect.
On Sun, 13 Feb 2011 10:02:33 -0500 (EST) bdawes@acm.org wrote:
Author: bemandawes Date: 2011-02-13 10:02:27 EST (Sun, 13 Feb 2011) New Revision: 68837 URL: http://svn.boost.org/trac/boost/changeset/68837
Log: Merge changes from https://github.com/Beman/filesystem. Important changes include fix for serious Windows reparse point bug, code cleanup, reference doc fixes and addition of missing functions, and the addition of symlink_option for recursive_directory_iterator...
So you're just going to squash git commits and apply them at once :(?
The ideal, of course, is to commit to SVN with granularity equivalent one logical change. So that might mean a commit covering implementation code, test code, and docs updates for a single bug. The reality is messier; I should have broken the set of changes above into three SVN commits, but hadn't gotten the procedure straight yet.
It is in bad form in the Boost world to commit multiple changes at once, as this makes it harder to track down breaking changes.
It seems clear to me that this is a violation of our Boost SVN policies and culture. Where is the list discussion about this change?
Commits should be made atomically. And you should not squash commits together - if there is a problem with a change you make, it becomes harder for others (or yourself) to revert it. This is a mistake that I myself have made in the past. Steven was reverting changes that I made to Boost.Config - other, valid changes to Boost configuration were also changed in the same commit.
Yep, that's certainly the best way to do it.
On Sun, 13 Feb 2011 09:48:03 -0500 (EST) bdawes@acm.org wrote:
Author: bemandawes Date: 2011-02-13 09:48:01 EST (Sun, 13 Feb 2011) New Revision: 68836 URL: http://svn.boost.org/trac/boost/changeset/68836
Log: Initial commit; bitmask.hpp is needed by upcoming filesystem changes Added: trunk/boost/detail/bitmask.hpp (contents, props changed)
Where is the list discussion about this speculative addition to the Boost detail headers? Why is this not in filesystem, if it is code that filesystem needs?
Because its going to be needed by other Boost libraries. It becomes more useful as compilers start to support scoped enums where there isn't any implicit conversion to int. --Beman
On Sun, Feb 13, 2011 at 11:15:55AM -0500, Beman Dawes wrote:
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
Note that the final two mklink steps are _not_ performable as a standard user, they require administrative privileges. The only kind of link I seem to be able to create as a standard test user on my machine is a file hardlink. Keep this in mind for Ryppl and whatever processes that might be proposed for Boost adoption, as anything that requires admin privileges will be completely unfeasible for many users of the library, and quite possibly for library contributors as well. -- Lars Viklund | zao@acc.umu.se
On Sun, Feb 13, 2011 at 08:12:06PM +0100, Lars Viklund wrote:
On Sun, Feb 13, 2011 at 11:15:55AM -0500, Beman Dawes wrote:
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
Note that the final two mklink steps are _not_ performable as a standard user, they require administrative privileges.
The only kind of link I seem to be able to create as a standard test user on my machine is a file hardlink.
Keep this in mind for Ryppl and whatever processes that might be proposed for Boost adoption, as anything that requires admin privileges will be completely unfeasible for many users of the library, and quite possibly for library contributors as well.
I forgot to mention, what will happen if you're on a filesystem not NTFS, like a network drive, a thumbstick or a NFS mount, or on a Windows not Vista+? -- Lars Viklund | zao@acc.umu.se
On Sun, Feb 13, 2011 at 2:20 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Sun, Feb 13, 2011 at 08:12:06PM +0100, Lars Viklund wrote:
On Sun, Feb 13, 2011 at 11:15:55AM -0500, Beman Dawes wrote:
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
Note that the final two mklink steps are _not_ performable as a standard user, they require administrative privileges.
The only kind of link I seem to be able to create as a standard test user on my machine is a file hardlink.
Keep this in mind for Ryppl and whatever processes that might be proposed for Boost adoption, as anything that requires admin privileges will be completely unfeasible for many users of the library, and quite possibly for library contributors as well.
I forgot to mention, what will happen if you're on a filesystem not NTFS, like a network drive, a thumbstick or a NFS mount, or on a Windows not Vista+?
The Ryppl folks are well aware of those issues, and so they generate forwarding headers. One of my concerns was that I wanted to be sure that symlinks worked for boost developers when available. Most modern hard-disk filesystems support symlinks so it would be a shame if boost developers couldn't make use of them when available. --Beman
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
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
On 2/14/2011 5:59 AM, Beman Dawes wrote:
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.
You create a branch where you put the module, i.e. where you do all your work. When you want to publish, you merge/push to a common tree (or to another branch of the same marked as "release", or "trunk", etc.). It's the same development model, except it's all done in SVN. [...]
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.
I thought the part of the experiment was to compare against SVN? And obviously comparing against our current use of SVN would be an unfair comparison. Since if there's a way to use the current tools in the same way as Git would that not be a reasonable choice to move to? I.e. would it not be a reasonable choice to move to using SVN with modular libraries? I guess I've lost what the point of experimentation is without looking at all the immediate alternatives :-\ -- -- 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
On Mon, Feb 14, 2011 at 12:59, Beman Dawes <bdawes@acm.org> wrote:
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.
The core idea being to have repositories by libraries (if I understood correctly) or something similar, maybe using the "externals" feature of SVN (http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.externals ) There would be as much repos as libraries, with maybe a central one using externals to "bind them all". That would be the same idea anyway with other DSVC I guess (using the "subrepo" features that are similar to externals but implemented in another way). The main problem (other than moving repos) would then be to have enough resources host each library (I mean server time/space/bandwidth). That could be fixed by putting everything on Sourceforge or similar websites, instead of just one big server. This kind of organisation is easier to setup with dsvc but it's still doable with SVN too.
participants (9)
-
Beman Dawes -
Bryce Lelbach -
Daniel Larimer -
Hartmut Kaiser -
Joel Falcou -
Klaim - Joël Lamotte -
Lars Viklund -
Rene Rivera -
Steven Watanabe