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