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.
[snip]
> 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).
[snip]
> 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.
[snip]
> 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.
Daniel