Re: [boost] trunk vs release

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