simple use case advice

[Martin Pool]

On 1 October 2010 05:45, Chris Hecker <checker at d6.com> 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?

The best answer depends a bit on whether you just committed the broken
one or whether you've done other work after that; whether the binary
search you're talking about is only through the changes in one
revision or through many; whether other people have already built on
the problematic code; and whether you want to ultimately end up with
history that shows the error being introduced then later fixed, or
never happening.

If it's a simple matter of you just committed, then realized the
commit was broken, I would uncommit, change it the way you want, then
recommit.

If the change was several revisions back, I would merge a reversal of
the problematic change, then adjust to suit, eg

 bzr merge -r N+1..N .

If you want to make multiple branches and your tree is so large that
either checking it out or compiling it (or both) is painful, then I
would recommend you install lp:bzr-colo and run 'bzr help colo', so
you can have one tree and switch it around.

hth

-- 
Martin