Re: [boost] [1.37.0] branches/release open for merges

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2008-08-20 13:38:37

Beman Dawes wrote:
> Gennaro Prota wrote:
>> Daryle Walker wrote:
>>> On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
>>>
>>>> Gennaro Prota wrote:
>>     [...]
>>>>> where does the release branch originate from?
>>>>
>>>> It's always from the previous release.
>>>
>>>
>>> Is this a good thing?
>>
>> Not to me. I imagine that, in a time in which I wasn't following the 
>> list, there have been long discussions which led to the current state 
>> of affairs. So, it may be clear to everyone except me. What I know 
>> for sure is that this requires *a lot* of work every time you make a 
>> modification; and either a lot of memory on your part, or a file 
>> where you note the inter-release changes down, detailedly (I 
>> certainly don't trust merging a whole directory (or multiple ones) 
>> blindly: I want to see exactly what gets merged; and, to do this, I 
>> have to keep a list of what changes I made). With such an approach, 
>> I'd expect more problems due to naive merges than problems due to an 
>> unstable trunk version being used as a branch point.
>
> Whoa! None of that has to be done manually. Subversion provides plenty 
> of tools to manage differences between trunk and branches/release.
>
> There are several ways to go about merging. One procedure is to switch 
> your working copy to branches/release, merge changes from 
> branches/release to trunk into your working copy, and then view the 
> differences. The only thing even remotely tricky is to remember the 
> diff to be merged is from branches/release to trunk, not the other way 
> around.
>
> If all changes are to be merge, you are ready to commit. But if only 
> some changes are to be merged, or just to be sure, I view the diff 
> between the merged but not yet committed working copy and the repository.
I'm still not sure I completely understand, sorry. I'm typically only 
working on trunk, unless I have last-minute fixes that need to be 
applied, in which case I apply them to trunk, as well as the (current) 
release branch. Hopefully this is all I have to care about. Is this 
indeed so ?

If you start working on the 37 release, using the 1_36 branch, who is in 
charge of merging the new stuff that went into trunk but isn't present 
in the 1_36 branch ? I sure hope it's not me.

Thanks,
       Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...