Beman Dawes writes:

On Sun, Nov 24, 2013 at 6:21 PM, Daniel James wrote:

...

On 24 November 2013 22:57, Beman Dawes wrote:

...

The branches/release vs master comparison is in pretty good shape - no missing headers, but a small number of extra headers. Two libraries are affected.

The extra functional/hash headers were deleted a long time ago. "Attic" directories were used by CVS for deleted files, so I'm guessing there was a mistake in the CVS to subversion conversion which confused the subversion to git conversion. It's a bit annoying, but not a show stopper.

Agreed.

...

...

But the trunk vs develop comparison turned up problems in many libraries. For example, the whole Boost.Chrono stopwatches sub-directory is missing.

That directory is in develop:

https://github.com/boostorg/chrono/tree/develop/include/boost/chrono/stopwat...

Maybe it's using the master branch for submodules. How are you checking it out?

Argh! That's almost certainly the problem. What is the easiest way to checkout the develop branch from all submodules?

There should be a develop branch in the super repo that references the tip of develop in all submodules. Just check that branch out and "git submodule update," neh?

On 25 November 2013 01:56, Beman Dawes wrote:

On Sun, Nov 24, 2013 at 8:10 PM, Dave Abrahams wrote:

...

Beman Dawes writes:

...

On Sun, Nov 24, 2013 at 6:21 PM, Daniel James

...

Maybe it's using the master branch for submodules. How are you checking it out?

Argh! That's almost certainly the problem. What is the easiest way to checkout the develop branch from all submodules?

There should be a develop branch in the super repo that references the tip of develop in all submodules. Just check that branch out and "git submodule update," neh?

Ah! Excellent! That's easier than the script I was using.

And the problem was definitely operator error on my part. Sorry for the noise. The corrected run shows four extra files, plus sync missing. See attached.

The directory libs/sync is present in my super-project clone but is empty. Looking at boostorg on GitHub, sync doesn't have a master branch, so maybe is getting dropped on the floor as far as the clone goes?

I just tried: git clone --recursive -b develop git@github.com:boostorg/boost.git boost-develop And that worked fine. I think you're doing a recursive clone of master and then switching to the branch. In which case I think you need to use 'git submodule update --init' to initialise modules on this branch before updating (untested and possibly wrong). Will most developers use this though? I imagine they'd check out the master and then use develop for the modules they care about.

On 25 November 2013 14:07, Beman Dawes wrote:

On Mon, Nov 25, 2013 at 8:18 AM, Daniel James wrote: ...

...

just tried:

git clone --recursive -b develop git@github.com:boostorg/boost.git boost-develop

And that worked fine.

I think you're doing a recursive clone of master and then switching to the branch. In which case I think you need to use 'git submodule update --init' to initialise modules on this branch before updating (untested and possibly wrong).

At Dave's suggestion, I tried this last night:

git clone --recursive git@github.com:boostorg/boost.git modular-boost cd modular-boost ... git checkout develop git module update

It worked fine, and that's what I used to run the develop header file verification that worked correctly.

But it was missing sync, wasn't it? That's why I think you need to use 'git module update --init'.

git clone --recursive git@github.com:boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers git checkout master git submodule update cd libs/my-lib git checkout develop [...] Is the sequence of commands above what the developer of my-lib should do to get started?

I didn't need 'git checkout master' and 'git submodule update'. The wiki page says the modular-boost repo will be detached, but it wasn't for me (the submodules were).

Daniel James writes:

On 25 November 2013 14:07, Beman Dawes wrote:

...

On Mon, Nov 25, 2013 at 8:18 AM, Daniel James wrote: ...

...

just tried:

git clone --recursive -b develop git@github.com:boostorg/boost.git boost-develop

And that worked fine.

I think you're doing a recursive clone of master and then switching to the branch. In which case I think you need to use 'git submodule update --init' to initialise modules on this branch before updating (untested and possibly wrong).

At Dave's suggestion, I tried this last night:

git clone --recursive git@github.com:boostorg/boost.git modular-boost cd modular-boost ... git checkout develop git module update

It worked fine, and that's what I used to run the develop header file verification that worked correctly.

But it was missing sync, wasn't it? That's why I think you need to use 'git module update --init'.

I think you would need --init if the branch to which you were switching contained submodules that weren't present in the branch from which you were switching. In any case, it can't hurt.

...

git clone --recursive git@github.com:boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers git checkout master git submodule update cd libs/my-lib git checkout develop [...] Is the sequence of commands above what the developer of my-lib should do to get started?

I didn't need 'git checkout master' and 'git submodule update'. The wiki page says the modular-boost repo will be detached, but it wasn't for me (the submodules were).

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Mon, Nov 25, 2013 at 8:47 AM, tim wrote:

...

The directory libs/sync is present in my super-project clone but is empty. Looking at boostorg on GitHub, sync doesn't have a master branch, so maybe is getting dropped on the floor as far as the clone goes?

boost.sync is part of trunk, but hasn't been merged into release (it is mainly broken out of thread and log with a few additions).

maybe that's the reason why no master branch is generated?

That's what I'm assuming happened. And so the conversion is right not to include sync as a sub-module of the super-project. --Beman