stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject on branches and merging (was: Re: failing regression tests)
Date Tue, 01 Apr 2008 22:10:31 GMT
Martin Sebor wrote:
> Travis Vitek wrote:
>>  
>>
>>> Martin Sebor wrote:
[...]
>>> I think we need to decide if trunk is supposed to be a copy of
>>> 4.2.x or if it's for development of future versions. If the
>>> latter, there's no problem with keeping tests like it there
>>> as long as they're passing or as long as there's an entry in
>>> xfail.txt. We just need to remember not to merge them (and
>>> fixes for them, if they're incompatible) out to 4.2.x.
>>>
>>> So, which is it? Do we keep trunk as a development version of
>>> 4.2.x or do we make changes on it that are incompatible with
>>> 4.2.x?
>>>
>>
>> I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
>> and future work should be done on trunk until an appropriate branch has
>> been created. That way we avoid having to be careful about bulk merges
>> from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
>> trunk.
>>
>> Unfortunately, I think that would mean that we would need to do nightly
>> testing on the 4.2.x branch, possibly in addition to trunk.
> 
> Right, that's a big problem. Another problem with this approach
> is that it has the potential to destabilize the branch.
> 
> The second problem can be mitigated by tagging the branch when
> it's known to be stable. I don't think there's anything we can
> do about the first problem except alleviate it by implementing
> a more intelligent test harness. I'm not sure we have cycles
> for that...

It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?

> 
> Is there some convention or process we could put in place that
> would make the bulk merge issue less painful? I wake up in the
> middle of the night thinking about how we're going to manage
> it for 4.2.1. Maybe it won't be so bad, but it does seem like
> it will be a lot work and could be pretty error prone.
> 
> Martin
> 


Mime
View raw message