Proper handling of merging between branches

[David Muir]

Mark A. Flacy wrote:
> On Tue, 2010-10-12 at 14:19 +1100, Martin Pool wrote:
>   
>> I think the approach there is basically reasonable.
>>
>> Some other variations:
>>
>>  * after you do a 'major release' when everything from trunk is merged
>> into staging, then pull staging back to trunk; that way trunk never
>> goes very far away or develops its own ancestry
>>  * cherrypick the change into trunk, so that you bring across only the
>> critical fix, and nothing else
>>  * get rid of trunk as a branch in its own right and just have feature
>> branches that merge into staging when they're stable (or perhaps this
>> is better said as, have only a trunk that stays deployable)
>>     
>
> There's also the idea of the tofu-scale.  See
> http://stackoverflow.com/questions/1311849/using-the-tofu-scale-with-svn
> as well as the PDF file linked in the above article
> (http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf)
>
>   
Thanks for the suggestions.
Since it's not something I do very often, merging without parents or 
cherrypicking should work well, I think.
As for minimising conflicts, would the tofu model work better? As in, 
would it be better to do the fix in trunk, then cherrypick to staging? 
Or are conflicts just as likely in that situation?

left  = trunk
right = staging
    
|  D  //conflict?
| /|  //merge
C  |
|  |
A->B  //cherrypick  

vs

|  E  //conflict?
| /|  //merge
D  |
|  |
C  | 
| \| //merge without parents
|  B    


Cheers,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101012/5212ffd2/attachment.htm