|
|
Boost : |
Subject: Re: [boost] [Git] Boost Filesystem now has public GitHub repository
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-02-13 15:03:54
On Sun, Feb 13, 2011 at 1:42 PM, Bryce Lelbach
<admin_at_[hidden]> wrote:
> Beman Dawes <bdawes_at_[hidden]> 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_at_[hidden]> 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_at_[hidden] 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_at_[hidden] 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk