simple use case advice
Gordon Tyler
gordon.tyler at gmail.com
Thu Sep 30 23:32:14 BST 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/30/2010 3:45 PM, 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?
As far as I understand the concept of "daggy fixes"
(http://monotone.ca/wiki/DaggyFixes/) is you branch from the revision
where the error was *introduced*, fix on the branch and the merge into
your active branches. Thus, in your case, you would branch from rev N+1,
fix the bug and then merge that branch back into trunk.
Ciao,
Gordon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMpQ/uAAoJEIrPJfWinA2uXNcH/3s1BPdusSCrUOHJ1gkLxIaw
UUWf9qym2L+CxITa4FKNcoqSGPtVLgpHchcrZftZihKxfWGkxOoEV2yK0RsLQOot
kk8L8PkKDqk52LyRosNvygjWXV5nFL5a2dj5Q5uD8p7baPo0wIQ1W1+dqjFpWwou
Vty/b+03dvjwrruoygWBTcI9HNc8c2BJBa6LwQMlBjQQ7IekHz5z3pyuk6OGqxvP
vx4DVcCPDRZfxS2P7BwM6kfX8UovmEs/z7b3Hxx9vjjJPOlCr0zFjmgrschZoP7N
hcUingTUY6Aut2uAhFYusXgbLzPFEnDxFL1H9ySUtRvCedrEOGgTKbT4ia3n1LE=
=Seed
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list