simple use case advice

[Alexander Belchenko]

Chris Hecker пишет:
> 
> Oh, and one downside of this plan is having to clean build the whole
> project again.  I guess that's what the colocated branch thing is about?

Yes.

> 
> Chris
> 
> 
> On 2010/09/30 12:45, Chris Hecker wrote:
>>
>>> Some people favor doing the binary search and then branching at
>>> *that* point.
>>
>> Hmm, what do you mean? I've got the changelist where the break happens,
>> that's N+1. N works fine. It's just a relatively big change, so there's
>> going to be some code-wise binary searching as well. So, to be clear
>> since I'm a dvcs noob:
>>
>> - I bzr branch -r N trunk work
>> - I figure out where the bug in work is, and fix it (I assume bzr will
>> let me diff the other branch to help out here, any other good tricks for
>> diffing or merging parts of N+1?)
>> - I get work to equivalent to trunk at N+1+bugfix
>> - bzr merge work trunk
>> - bzr ci trunk
>> - rm work
>>
>> right? Will the merge from work -> trunk be a mess, even though they're
>> likely to be very similar?
>>
>> Thanks,
>> Chris
>>
>>
>> On 2010/09/30 11:56, John Arbash Meinel wrote:
> On 9/30/2010 1:10 PM, Chris Hecker wrote:
>>>>>
>>>>> I've got a branch, and version N works, and version N+1 doesn't. I
>>>>> already checked in N+1. In the old days, I'd roll back to N, keeping a
>>>>> separate manual copy of N+1, and do the binary search thing, then sync
>>>>> to N+1 and fix the problem.
>>>>>
>>>>> Is there a fancy dvcs way to make this easier? Should I just make a new
>>>>> branch at N, then do the work there, checking in, until it's
>>>>> N+1+bugfix,
>>>>> then merge that over to the main branch?
> 
> Some people favor doing the binary search and then branching at *that*
> point.
> 
> But yes, creating a new branch, and then merging the fix in is the usual
> way of doing it.
> 
> John
> =:->
> 
> 
>>>>>
>>>>> Hopefully that makes sense.
>>>>>
>>>>> Chris
> 
> 
>>>