Help with gatekeeper workflow.

[Marius Kruger]

2009/3/4 Eric Berry <elberry at gmail.com>

> The problem with this approach is that we get the merges from trunk as part
> of Joe's history - which isn't bad, but can distract Bob from Joe's real
> changes.


I don't think its that bad or that it is really avoidable other than using
`bzr replay` from the rebase plugin.
I think if you standardize the merge commit message eg. "merge main",
you should be able to ignore them easily enough.
After you merge his changes into main,
`bzr diff` would in any case show you all the real changes he made.

To avoid the merges from trunk in the history, another approach is to have
> Joe create a local branch of the main branch which he commits work to, and
> he merges changes from the main branch regularly. When he is finished with
> his work, he uses diff to create a patch which he then sends to Bob to
> apply. After Bob approves of the changes, he applies the patch locally and
> commits the changes upwards to the main branch. The problem with this
> approach is that we lose all the history of Joe's commits in the main
> branch.


this is bad, don't even consider it IMHO

-- 
<| regards
U| Marius
H| <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090304/daa5cd81/attachment.htm