Moving to Git revision

[Jon Kalb]

I’ve revised the plan based on feedback from Daniel and Dave. Did I miss any feedback?

I’ve put it into the Trac Wiki here:

https://svn.boost.org/trac/boost/wiki/ModCvtSchedule

I’ve pulled the date in based on Dave’s comment. This means that the preliminary documentation, the FAQ, and the Help Desk need to come together very soon. I think Beman is working on some documentation and the Help Desk. I think he is open to ideas about how the Help Desk should be implemented. Please contact him if you are interested in helping the Help Desk take shape.

Are there other comments?

I’d like to have a formal vote on this and then announce it on the mailing lists and the website. Are we ready for a formal vote? Are there more changes that we need to see made or questions that we need answers to?

So far I’ve gotten only two votes (including mine) for the Standard C++ Foundation vote. Granted that may be moot given the information we’ve gotten from Eric, but I’ve only gotten three votes (including mine) on the FSA vote. Please vote (even if you are abstaining). If you think you have voted and your name is not Dave or Hartmut, them please let me know because it didn’t get recorded.

Jon

[Eric Niebler]

On 12/1/2012 4:07 PM, Jon Kalb wrote:
>
> ... I’ve only gotten three votes (including mine) on the FSA vote.
> */Please vote /*(even if you are abstaining). If you think you have

> voted and your name is not Dave or Hartmut, them please let me know
> because it didn’t get recorded.

I mailed you privately about this, but I didn't hear back. There's a
problem with the FSA; it doesn't have my name on it. At least, I
assume it's meant to. I've been waiting to hear back from you.

The opening sentence is wrong:

> This Agreement is made by and between The Software Freedom
> Conservancy (“Conservancy”) and David Abrahams, Marshall Clow, Beman
> Dawes, Hartmut Kaiser, Jeff Garland, Jon Kalb, Robert Stewart, and
> Steven Watanabe (the “Current Committee”) on behalf of the project
> known as Boost (the “Project”).

Also, at the end there's lines for everybody to sign but me.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

[Eric Niebler]

On 12/1/2012 4:07 PM, Jon Kalb wrote:
>

> I’ve revised the plan based on feedback from Daniel and Dave. Did I miss
> any feedback?
>
> I’ve put it into the Trac Wiki here:
>
> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
>
> I’ve pulled the date in based on Dave’s comment. This means that the
> preliminary documentation, the FAQ, and the Help Desk need to come
> together very soon. I think Beman is working on some documentation and
> the Help Desk. I think he is open to ideas about how the Help Desk
> should be implemented. Please contact him if you are interested in
> helping the Help Desk take shape.
>
> Are there other comments?

I'd like to see something said about the svn history. Ideally, we'd have
a git repo that has history up to date X and a script for grafting it
onto the submodules. That should be checked in to the boost-lib
supermodule so that devs can run it and it just happens. This should
work in time for "Developers beta test Git repository", since they'll
want to be able to test history, too.

Also, when svn is made read-only and the final pull happens, we'll also
do the final svn history conversion. We probably want clean repos for
all of that, right?

[Jon Kalb]

On 12/1/12 6:46 PM, "Eric Niebler" <er...@boostpro.com> wrote:

> On 12/1/2012 4:07 PM, Jon Kalb wrote:
>>
>> I¹ve revised the plan based on feedback from Daniel and Dave. Did I miss
>> any feedback?
>>
>> I¹ve put it into the Trac Wiki here:
>>
>> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
>>
>> I¹ve pulled the date in based on Dave¹s comment. This means that the
>> preliminary documentation, the FAQ, and the Help Desk need to come
>> together very soon. I think Beman is working on some documentation and
>> the Help Desk. I think he is open to ideas about how the Help Desk
>> should be implemented. Please contact him if you are interested in
>> helping the Help Desk take shape.
>>
>> Are there other comments?
>
> I'd like to see something said about the svn history. Ideally, we'd have
> a git repo that has history up to date X and a script for grafting it
> onto the submodules. That should be checked in to the boost-lib
> supermodule so that devs can run it and it just happens. This should
> work in time for "Developers beta test Git repository", since they'll
> want to be able to test history, too.

I'm not certain I understand what your saying. From what Beman told me, I
thought that a lot of history had been moved over, but he indicated that it
might not be 100% and I don't know if he was saying that the history was
converted as a certain point, or if there is a script that can be run at any
time to convert history as of then.

Can anyone clarify? Eric can you update this page to reflect what you think
it should say?
https://svn.boost.org/trac/boost/wiki/ModCvtSchedule

> Also, when svn is made read-only and the final pull happens, we'll also
> do the final svn history conversion. We probably want clean repos for
> all of that, right?

I think that's what I mean by the second item on 2013-01-28: "Repositories
at github.com/boost/boost-lib/* are recreated and blessed." I think these
were Daniel's words and I assumed they meant "clean repros."

Jon

[Jon Kalb]

On 12/1/12 5:59 PM, "Eric Niebler" <er...@boostpro.com> wrote:

> On 12/1/2012 4:07 PM, Jon Kalb wrote:
>>
>> ... I¹ve only gotten three votes (including mine) on the FSA vote.
>> */Please vote /*(even if you are abstaining). If you think you have
>> voted and your name is not Dave or Hartmut, them please let me know
>> because it didn¹t get recorded.
>
> I mailed you privately about this, but I didn't hear back. There's a
> problem with the FSA; it doesn't have my name on it. At least, I
> assume it's meant to. I've been waiting to hear back from you.
>
> The opening sentence is wrong:
>
>> This Agreement is made by and between The Software Freedom
>> Conservancy (³Conservancy²) and David Abrahams, Marshall Clow, Beman

>> Dawes, Hartmut Kaiser, Jeff Garland, Jon Kalb, Robert Stewart, and

>> Steven Watanabe (the ³Current Committee²) on behalf of the project
>> known as Boost (the ³Project²).
>
> Also, at the end there's lines for everybody to sign but me.

We'll need the Conservancy to provide an up-to-date version that addresses
this as well as any dates and account balances.

Jon

[Eric Niebler]

On 12/2/2012 10:11 PM, Jon Kalb wrote:
> On 12/1/12 6:46 PM, "Eric Niebler" <er...@boostpro.com> wrote:
>> On 12/1/2012 4:07 PM, Jon Kalb wrote:
>>>

>>> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
<snip>

>>
>> I'd like to see something said about the svn history. Ideally, we'd have
>> a git repo that has history up to date X and a script for grafting it
>> onto the submodules. That should be checked in to the boost-lib
>> supermodule so that devs can run it and it just happens. This should
>> work in time for "Developers beta test Git repository", since they'll
>> want to be able to test history, too.
>
> I'm not certain I understand what your saying. From what Beman told me, I
> thought that a lot of history had been moved over, but he indicated that it
> might not be 100% and I don't know if he was saying that the history was
> converted as a certain point, or if there is a script that can be run at any
> time to convert history as of then.

Ah, there are some details of the conversion that are not as widely
known as I thought! Here's (my understanding of) how it will work:

- The modularized repos will have *no* history.
- The super-module will also have *no* history.
- The history will be in its own repo. There will be an option, as a
separate step, to "graft" the history onto each sub-module through deep
git magic that I don't understand.

Why? Because we don't want each and every sub-module to contain the
entire ancient history of Boost. That would be gross duplication that
takes up lots of space on everybody's machines (since with git, all
history is local).

> Can anyone clarify? Eric can you update this page to reflect what you think
> it should say?
> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule

I'm not sure I'm the best person to do this, since the plan may have
changed since I was involved.

>> Also, when svn is made read-only and the final pull happens, we'll also
>> do the final svn history conversion. We probably want clean repos for
>> all of that, right?
>
> I think that's what I mean by the second item on 2013-01-28: "Repositories
> at github.com/boost/boost-lib/* are recreated and blessed." I think these
> were Daniel's words and I assumed they meant "clean repros."

Good.

[Nevin Liber]

On 3 December 2012 14:30, Eric Niebler <er...@boostpro.com> wrote:

- The modularized repos will have *no* history.

- The super-module will also have *no* history.
- The history will be in its own repo. There will be an option, as a
separate step, to "graft" the history onto each sub-module through deep
git magic that I don't understand.

Why? Because we don't want each and every sub-module to contain the
entire ancient history of Boost. That would be gross duplication that
takes up lots of space on everybody's machines (since with git, all
history is local).

So, is there a longer term plan to periodically purge "history" from Boost repos?  If not, this seems like a rationalization, not a justification.

Personally, I'd rather see the history with it; that information is invaluable when tracking down problems, and any non-ordinary steps required to get at it make it that much more painful.  Isn't the point behind version control to be able to look at the history?  While I agree the older the history is the less likely it is one will ever need to look at it, that need is still non-zero.

-- 

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[Eric Niebler]

On 12/3/2012 12:44 PM, Nevin Liber wrote:

> On 3 December 2012 14:30, Eric Niebler wrote:
>
>> - The modularized repos will have *no* history.
>> - The super-module will also have *no* history.
>> - The history will be in its own repo. There will be an option, as
>> a separate step, to "graft" the history onto each sub-module
>> through deep git magic that I don't understand.
>>
>> Why? Because we don't want each and every sub-module to contain
>> the entire ancient history of Boost. That would be gross
>> duplication that takes up lots of space on everybody's machines
>> (since with git, all history is local).
>
> So, is there a longer term plan to periodically purge "history" from
> Boost repos? If not, this seems like a rationalization, not a
> justification.

Why would you ever want to purge history?

> Personally, I'd rather see the history with it; that information is
> invaluable when tracking down problems, and any non-ordinary steps
> required to get at it make it that much more painful. Isn't the
> point behind version control to be able to look at the history?
> While I agree the older the history is the less likely it is one will
> ever need to look at it, that need is still non-zero.

The history will be there. It's a one time operation to make the history
available to all boost submodules. I imagine there will be *one* script
that will pull down the supermodule, initialize all the submodules *and*
graft on history. Most people wouldn't even be the wiser. I don't see
this as a problem -- as long as it is really that transparent. It's
something we need to test, though, which is why I bring it up.

[Nevin Liber]

On 3 December 2012 14:50, Eric Niebler <er...@boostpro.com> wrote:

>> Why? Because we don't want each and every sub-module to contain
>> the entire ancient history of Boost. That would be gross
>> duplication that takes up lots of space on everybody's machines
>> (since with git, all history is local).
>
> So, is there a longer term plan to periodically purge "history" from
> Boost repos?  If not, this seems like a rationalization, not a
> justification.

Why would you ever want to purge history?

The same reason:  the git repository gets "too big" in that we don't want to waste disk space on client machines.  Note:  By purge I don't mean forever; just from the "typical" distribution.

 

The history will be there. It's a one time operation to make the history
available to all boost submodules. I imagine there will be *one* script
that will pull down the supermodule, initialize all the submodules *and*
graft on history. Most people wouldn't even be the wiser. I don't see
this as a problem -- as long as it is really that transparent. It's
something we need to test, though, which is why I bring it up.

Agreed.

[Dave Abrahams]

on Mon Dec 03 2012, Nevin Liber <nevin-AT-eviloverlord.com> wrote:

> On 3 December 2012 14:30, Eric Niebler <er...@boostpro.com> wrote:
>
> - The modularized repos will have *no* history.
> - The super-module will also have *no* history.
> - The history will be in its own repo. There will be an option,
> as a
> separate step, to "graft" the history onto each sub-module
> through deep
> git magic that I don't understand.
>
> Why? Because we don't want each and every sub-module to contain
> the entire ancient history of Boost. That would be gross
> duplication that takes up lots of space on everybody's machines
> (since with git, all history is local).
>
>
> So, is there a longer term plan to periodically purge "history" from
> Boost repos?  

No. And like Eric I don't see why we'd want to.

> If not, this seems like a rationalization, not a justification.

How's this for a justification? If you ever want to bring the complete
histories of multiple libraries back together into the same repository,
it'll may be a lot easier with a graft than if you have to resolve the
varying fates of any files that may exist in the two repositories.

Plus, it gives us valuable flexibility without lock-in. We're not sure
exactly what the most useful view will be of the transition between
non-modular and modular layouts, and if ancient history is grafted on,
it'll be easier for users to experiment and change that. Initially we
expect the transition to look like many files getting deleted and a few
getting moved, all in one commit. Maybe it makes sense to do that in
two commits, though, for example. Or, maybe people will really want to
see a "synthesized" history that isn't historically accurate but tracks
all their old changes in their new locations and doesn't include changes
to other libraries. In fact, I can imagine this latter view being the
most useful of all. But since it's fictional, I don't think we want to
lock it in as the only view.

> Personally, I'd rather see the history with it; that information is
> invaluable when tracking down problems, and any non-ordinary steps
> required to get at it make it that much more painful.  Isn't the
> point behind version control to be able to look at the history?

Yes.

>  While I agree the older the history is the less likely it is one
> will ever need to look at it, that need is still non-zero.

Of course. That's why we think it's important to provide it. We could
do this either way, of course, but I think the graft is a much safer and
more flexible way.

--
Dave Abrahams
BoostPro Computing Software Development Training
http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

[Dave Abrahams]

Huh. Do you imagine this to be a very common thing to want to do? If
so, it doesn't really nullify the storage space considerations. There's
a way to get multiple repositories to share revision storage but I'm not
sure how to best set that up for a case like this.

[Eric Niebler]

Maybe not common. But if the history repo isn't too big, then why not be
proactive? If it's big, maybe the script could prompt. Or maybe some
"getting started" docs might be enough. Dunno. No strong feelings.

[Nevin Liber]

On 3 December 2012 15:36, Eric Niebler <er...@boostpro.com> wrote:

Maybe not common. But if the history repo isn't too big, then why not be

proactive? If it's big, maybe the script could prompt. Or maybe some
"getting started" docs might be enough. Dunno. No strong feelings.

I'm not of fan of "being special"; i.e., different than just about everyone else out there, thus requiring a specialized learning curve to overcome that barrier to entry.  Boost currently has a build process that is "special" and people generally don't like it.  I'd rather we not be "special" in getting access to history from git. 

[Dave Abrahams]

on Mon Dec 03 2012, Nevin Liber <nevin-AT-eviloverlord.com> wrote:

> On 3 December 2012 15:36, Eric Niebler <er...@boostpro.com> wrote:
>
> Maybe not common. But if the history repo isn't too big, then why
> not be
> proactive? If it's big, maybe the script could prompt. Or maybe
> some
> "getting started" docs might be enough. Dunno. No strong
> feelings.
>
>
> I'm not of fan of "being special"; i.e., different than just about
> everyone else out there, thus requiring a specialized learning curve
> to overcome that barrier to entry.  Boost currently has a build
> process that is "special" and people generally don't like it.  I'd
> rather we not be "special" in getting access to history from git. 

+1 but the alternatives look worse to me.

The history of boost takes up 233M in the .git directory (225M after a
Git GC). Multiply by 120 libraries and we're talking about 28G if
you're doing release management or testing. I personally don't think
that's acceptable.

[Dave Abrahams]

History is here: https://github.com/ryppl/boost-svn
The script runs continuously, though it's possible that something hung
it up recently; I don't see a commit in the past 18 days. I'll look
into that.

> Can anyone clarify? Eric can you update this page to reflect what you think
> it should say?
> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
>
>> Also, when svn is made read-only and the final pull happens, we'll also
>> do the final svn history conversion. We probably want clean repos for
>> all of that, right?
>
> I think that's what I mean by the second item on 2013-01-28: "Repositories
> at github.com/boost/boost-lib/* are recreated and blessed." I think these
> were Daniel's words and I assumed they meant "clean repros."

Yes.

[Dave Abrahams]

on Sat Dec 01 2012, Eric Niebler <eric-AT-boostpro.com> wrote:

> On 12/1/2012 4:07 PM, Jon Kalb wrote:
>>
>> I’ve revised the plan based on feedback from Daniel and Dave. Did I miss
>> any feedback?
>>
>> I’ve put it into the Trac Wiki here:
>
>>
>> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
>>
>> I’ve pulled the date in based on Dave’s comment. This means that the
>> preliminary documentation, the FAQ, and the Help Desk need to come
>> together very soon. I think Beman is working on some documentation and
>> the Help Desk. I think he is open to ideas about how the Help Desk
>> should be implemented. Please contact him if you are interested in
>> helping the Help Desk take shape.
>>
>> Are there other comments?
>
> I'd like to see something said about the svn history. Ideally, we'd have
> a git repo that has history up to date X and a script for grafting it
> onto the submodules.

I'm not sure the formula for invoking the script would be much shorter
than the formula for invoking "git replace" directly:
http://www.kernel.org/pub/software/scm/git/docs/git-replace.html

After fetching from the ancient history repo, it would probably look
like:

git replace trunk-history-root trunk-ancient-history-tip

or

git replace release-history-root release-ancient-history-tip

[Eric Niebler]

Sorry, maybe I'm just dense, but I don't see how this addresses my
request that the modularization action plan be updated with information
about the history migration. My suggestion is that a partial conversion
is ready for grafting after the first bullet (docs, help desk) and
before the second (developers beta-test git repos). That means that the
docs should also note how to graft the repo. Or something else, whatever
makes sense.

[Jon Kalb]

On 12/3/12 4:29 PM, "Dave Abrahams" <da...@boostpro.com> wrote:

>
> on Mon Dec 03 2012, Jon Kalb <jon-AT-kalbweb.com> wrote:
>
>> On 12/1/12 6:46 PM, "Eric Niebler" <er...@boostpro.com> wrote:
>>
>>> On 12/1/2012 4:07 PM, Jon Kalb wrote:

>>>> I¹ve put it into the Trac Wiki here:
>>>>
>>>> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule

>>> I'd like to see something said about the svn history. Ideally, we'd have
>>> a git repo that has history up to date X and a script for grafting it
>>> onto the submodules. That should be checked in to the boost-lib
>>> supermodule so that devs can run it and it just happens. This should
>>> work in time for "Developers beta test Git repository", since they'll
>>> want to be able to test history, too.
>>
>> I'm not certain I understand what your saying. From what Beman told me, I
>> thought that a lot of history had been moved over, but he indicated that it
>> might not be 100% and I don't know if he was saying that the history was
>> converted as a certain point, or if there is a script that can be run at any
>> time to convert history as of then.

I think I understand better now.

> History is here: https://github.com/ryppl/boost-svn
> The script runs continuously, though it's possible that something hung
> it up recently; I don't see a commit in the past 18 days. I'll look
> into that.

I've updated the wiki page to reflect this.

Is there/will there be a script for "grafting" history onto a submodule? Is
it done now? Will be be done in time for "Developers beta test Git
repository?"

Eric, Thanks for fixing my typos in the wiki.

Jon

[Beman Dawes]

On Mon, Dec 3, 2012 at 5:34 PM, Dave Abrahams <da...@boostpro.com> wrote:
>
> on Mon Dec 03 2012, Nevin Liber <nevin-AT-eviloverlord.com> wrote:
>
>> On 3 December 2012 15:36, Eric Niebler <er...@boostpro.com> wrote:
>>
>> Maybe not common. But if the history repo isn't too big, then why
>> not be
>> proactive? If it's big, maybe the script could prompt. Or maybe
>> some
>> "getting started" docs might be enough. Dunno. No strong
>> feelings.
>>
>>
>> I'm not of fan of "being special"; i.e., different than just about
>> everyone else out there, thus requiring a specialized learning curve
>> to overcome that barrier to entry. Boost currently has a build
>> process that is "special" and people generally don't like it. I'd
>> rather we not be "special" in getting access to history from git.
>
> +1 but the alternatives look worse to me.
>
> The history of boost takes up 233M in the .git directory (225M after a
> Git GC). Multiply by 120 libraries and we're talking about 28G if
> you're doing release management or testing. I personally don't think
> that's acceptable.

I've tried to capture some of this for the documentation. Please check
https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git and correct any
mistakes.

In particular, was it correct to say: 'Each individual Boost library's
public repository will contain a single branch, "master", that
corresponds to branches/release in Subversion'?

Thanks,

--Beman

[Dave Abrahams]

It wasn't intended to. It addresses your desire to have a script for
grafting history.

> My suggestion is that a partial conversion is ready for grafting after
> the first bullet (docs, help desk) and before the second (developers
> beta-test git repos). That means that the docs should also note how to
> graft the repo. Or something else, whatever makes sense.

FWIW, I think your suggestion makes sense. Why don't you go ahead and
add it?

[Dave Abrahams]

There will either be a script or a few sentences of instruction with a
one-liner git command. I'd prefer to write the latter but we'll have
how people react to the instructions.

[Dave Abrahams]

I think we also want to produce a branch called "develop" that
corresponds to trunk. Ideally we should also publish instructions for
anyone with an active svn branch other than trunk or release to create a
corresponding git branch. Inactive SVN development branches don't need
any special treatment.

I think I should make some diagrams that explain the structure of the
new repositories and what the git grafting process will do.

[Eric Niebler]

OK, done. I adjusted the dates accordingly, given 2 weeks to sort out
issues with the history conversion (which seems a bit up in the air atm).

Apologies if this interferes with the active vote on the schedule.
Comments welcome.

[Beman Dawes]

On Fri, Dec 7, 2012 at 4:20 PM, Dave Abrahams <da...@boostpro.com> wrote:
>
> on Thu Dec 06 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
>

>>...

>> In particular, was it correct to say: 'Each individual Boost library's
>> public repository will contain a single branch, "master", that
>> corresponds to branches/release in Subversion'?
>
> I think we also want to produce a branch called "develop" that
> corresponds to trunk.

That would be great! The more we can do to get developers off on the
right foot, the better.

Do we need to contact Daniel Pfeifer about that? I'm not sure he reads
this list.

-Beman

[Daniel Pfeifer]

2012/12/10 Beman Dawes <bda...@acm.org>

Yes, I am reading it.

Currently, the modularization script reads from svn trunk and writes to master.

But I agree that it should be: trunk -> develop; release -> master

I'll extend the script accordingly.

-Daniel

[Beman Dawes]

On Tue, Dec 11, 2012 at 1:37 AM, Daniel Pfeifer <purple...@gmail.com> wrote:

> Currently, the modularization script reads from svn trunk and writes to
> master.
> But I agree that it should be: trunk -> develop; release -> master
>
> I'll extend the script accordingly.

Thanks! Let me know when it is working, and I'll update the docs.

--Beman

[Daniel Pfeifer]

2012/12/11 Beman Dawes <bda...@acm.org>

Done. All the repositories at github.com/boost-lib now have two branches. The mapping is as follows:

svn trunk -> git develop

svn release -> git master

But this is not as intended, is it? Using Gitflow, "master" always contains the latest release. I am afraid this is not the case for the current "release" branch in svn.

Cheers, Daniel

[Dave Abrahams]

You have a good point, Daniel.  Any suggestions for how we should handle that?

--
Dave Abrahams
BoostPro Computing

http://www.boostpro.com

[Beman Dawes]

On Tue, Dec 25, 2012 at 10:27 PM, Dave Abrahams <da...@boostpro.com> wrote:
> You have a good point, Daniel. Any suggestions for how we should handle
> that?
>
>
> On Tue, Dec 25, 2012 at 6:18 PM, Daniel Pfeifer <dan...@pfeifer-mail.de>
> wrote:
>>
>> 2012/12/11 Beman Dawes <bda...@acm.org>
>>>
>>> On Tue, Dec 11, 2012 at 1:37 AM, Daniel Pfeifer <purple...@gmail.com>
>>> wrote:
>>>
>>> > Currently, the modularization script reads from svn trunk and writes to
>>> > master.
>>> > But I agree that it should be: trunk -> develop; release -> master
>>> >
>>> > I'll extend the script accordingly.
>>>
>>> Thanks! Let me know when it is working, and I'll update the docs.
>>
>>
>> Done. All the repositories at github.com/boost-lib now have two branches.

Thanks!

>> The mapping is as follows:
>>
>> svn trunk -> git develop
>> svn release -> git master

I assume you mean branches/release -> git master

>>
>> But this is not as intended, is it? Using Gitflow, "master" always
>> contains the latest release. I am afraid this is not the case for the
>> current "release" branch in svn.

Are you worried about a library whose svn trunk has been updated with,
say, a bug fix that passes all tests, but those fixes haven't been
merged yet to svn branches/release?

Is this any different from when a developer fixes a bug in "develop"
but "develop" hasn't yet been merged into "master"? I.E. a release
isn't a release until the fix is merged into "master", and it doesn't
matter whether the fix was done to svn branches/release before the
conversion or git develop after the conversion.

Or am I misunderstanding your concern?

There is also the question of how the Boost super-module finds out
about the new release of the developer's library. How is that going to
happen? Does the developer push a change to the Boost super-module?

--Beman