Re: [boost] [Boost.Sync] no master branch?

Subject: Re: [boost] [Boost.Sync] no master branch?
From: Tim Blechmann (tim_at_[hidden])
Date: 2014-01-15 12:59:11

>>>>> What is Boost.Sync and why doesn't its repository have a master branch?
>>>>
>>>> That library is a split of Boost.Thread that only contains synchronization
>>>> primitives. It's in an early development stage and not yet released, that's
>>>> why it has no master.
>>>>
>>>
>>>
>>> If it is an "early development stage", why is it in boostorg at all? Seems
>>> like it should be in the developer's own GitHub account.
>>
>> it was in trunk, but not in release. therefore it has a develop branch,
>> but no master. compare [1]. the functionality is not exactly new, but
>> broken out of boost.thread with some additions.
>>
>> tim
>>
>> [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/243511
> 
> Can you please explain the purpose of splitting these libraries? The
> only reason given in that discussion is, "For example, one of the
> benefits I'd like to achieve with this is that synchronization
> primitives should become decoupled from the timing libraries.":
> 
> Why is that desirable? Is that it?

one of the starting points for this library was the aim to unify some
duplicate functionality. e.g. log, smart_ptr and atomic require spinlock
implementations. personally, i'm maintaining spin-lock & semaphore
implementations for 2 different projects. log contains an implementation
of win32 events, i was submitting a patch for semaphores for boost.thread.

one idea was to place these classes into boost.thread, though andrey,
vicente and me had some discussions last summer and vicente proposed to
move the synchronization primitives out of boost.thread into a
boost.sync library. one of the reasons was also to have a lightweight
library, (almost) header-only.

there are arguments for and against having a separate boost.sync library
or to have this functionality. personally i don't care at all, because
it seems like a lovely source for a bikeshed discussion.

> As a practical matter, the sync repo should not be in boostorg until it
> has a master branch. I discovered this anomaly by trying to check out
> every repo in the master branch with this git command:

iirc there used to be libraries in the past, which had been in trunk,
but not in release.

>> git submodule foreach git checkout master
> 
> That command fails today because of sync.

iff you initialized the root project with the develop branch. but you
will *always* run into troubles if you have a git repository with
different branches if some branches contain a submodule which others don't.

boost's use of submodules is a bit controversial anyway, but that's
another discussion (one that i really don't want to start)

cheers,
tim