Workflow - Tracking upstream repository with local patches

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Moore wrote:
| I'm trying to work out what the optimal workflow would be with Bazaar
| for the following situation:
|
| I'm tracking an upstream project (which is using svn, not bzr, but
| that's not a big deal, I can use bzr-svn) where I only have read
| access. I have some local patches of my own, which I am working on,
| and which I would ultimately like to provide as a individual patches
| to the project.
|
| I think I need the following - a "clean" branch from upstream, into
| which I periodically pull changes, and a local branch for each of my
| patches, which I maintain and periodically merge from my upstream
| mirror. To submit a patch, I'd bzr diff between my branch and the
| upstream mirror, and submit that.
|
| One issue with this is that my feature branches' history will be
| cluttered with regular "merge from upstream" checkins. I can see the
| value of this, but it will clutter the history of my feature
| development. Is there any way of avoiding this? Would the loom
| extension help here?
|
| Does anyone have any suggestions as to how this workflow might be improved?
|
| Thanks,
| Paul.

I would guess it depends on how much you have to develop your patch. As
Alexander mentioned, you could rebase your patches each time you update from
upstream. The other possibility is to just use "uncommit" as appropriate.

So instead of having:

revno: 100
message:
~  My patch

revno: 101
message:
~  Merge from upstream

revno: 102
message:
~  Merge from upstream

revno: 103
message:
~  Merge from upstream

What you could do is update the pristine branch, and do the merge. After you fix
any conflicts, etc, you can then do:

bzr uncommit # pop off the last merge from upstream
bzr commit -m "Merge from upstream"

The reason to merge first is because you already spent some time merging
upstream and resolving conflicts. So by doing the next merge after it, you
preserve those changes, and bzr can pick a new base revision.

Then when you go to commit, you do a quick uncommit. Which changes that final
commit into a "fix up everything from my patch to the current tip". It
effectively brings in your other work while hiding it from ancestry.

That would leave you with:

revno: 100
message:
~  My patch

revno: 101
~  Merge from upstream

While 101 would keep changing to a different revision id.

Now, this stops working if:

1) You have to do more work on your patch after merging upstream. This is where
rebase works a little better because you end up with:

revno: 100
message:
~  upstream

revno: 101
~  My patch

However, it does so at the cost of changing the revision for your patch each
time. (Which is a bigger deal than changing the revision of a "merge from
upstream" change.)

2) Someone starts tracking your branch. This is a bit of an issue with any sort
of uncommit or rebase. Because now your official dip doesn't "descend" from
where it was, but jumps each time. So someone tracking you needs to use "pull
- --overwrite".


What I think you would really *like* is to have a way of developing your patch
on an independent branch. And then doing a "test" merge of upstream to make sure
it still applied. Clean up what needs cleaning up, and then revert out the merge
of upstream. There is a host of issues with this, though. As it means your patch
might not actually apply cleanly to the base it claims (since it was actually
applied/tested on a different tip.)
But conceptually if you are fixing a bug, then one should be able to merge a
bugfix without merging all of the development tip.

It sort of falls under the Daggy Fixes idea:
http://www.venge.net/mtn-wiki/DaggyFixes

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH2BVrJdeBCYSNAAMRAr5rAJ9JKo+OaYgG55oxbnkjwMp0pAMbvwCfQO4O
AnRVntMKXGnVtbbWtuQ3kVc=
=daTn
-----END PGP SIGNATURE-----