simple use case advice

[Chris Hecker]

> 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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyk3UQACgkQJdeBCYSNAAPXFQCgwfEb18/E/AxhUUZwy7oZCFKm
> fnAAnj8YNGSmxhpQr+3e12vuZ5Sp+OmW
> =KYVj
> -----END PGP SIGNATURE-----
>