Boost logo

Boost :

Subject: Re: [boost] trunk vs release
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-05-25 13:21:38

2009/5/25 troy d. straszheim <troy_at_[hidden]>:

>> [snip] If that results in a better testing system
>> and better modularization, that could improve the situation massively -
>> having a single tree for such disparate libraries that are developed
>> at different rates doesn't help.
> There's an ongoing assumption that modularization will help.

FWIW, I'm more interested in the testing system.


> And the one I'm interested in discussing now:
> - it enables one to more easily 'switchmerge' a single library. This is
> true. But is the need for this just a consequence of the fact that merging
> in svn is onerous/broken, no?

I don't think that's a big deal - if a library is orgranised well the
current system only requires two individual directories to be switched
(although I use svnmerge myself).


> It seems clear that the problem is lack of granularity. The trunk is a
> rather full, messy waiting room for the release branch. As the runup to a
> release comes, the release manager has little say in what uses testing
> resources.

Sure, but with our current testing and maintenance situation, I can't
see a realistic way around this.

> Is the prioritization backwards here? The linux kernel is twice as big.
> They can merge in seconds, and they do, (on the order of 4x/day iirc).

There's also a lot more effort and resources going into kernel development.

> [snipped a lot about git]

The major stumbling block is that git isn't good enough on windows.
Mercurial might be a better candidate, since it has TortoiseHg.
Although I haven't tried it myself.

There's also the administrative burden of moving to a new version
control system - we haven't even managed to upgrade from subversion
1.4 yet.

And I think a lot of boost developers just aren't that interested in
version control. Whatever we use will have to be usable with the
minimum of effort.

I wrote:
>> I think we are able to automatically identify which libraries most
>> headers belong to, so a tool which summarized the unchanged headers
>> might help. Anything which is left unmerged and untouched for some
>> time would be a cause for concern.

I think I was being overly optimistic here. Without merge tracking
it's hard to work out what's what.

> Right, there are ways to get in there and clean up the trunk, this is
> tractable. But it seems that if the system remains unchanged, the situation
> will naturally evolve again.

But I don't think it's that bad. It's yet to cause me any problems
with my libraries, although that might be because all of their
dependencies are very stable.


Boost list run by bdawes at, gregod at, cpdaniel at, john at