Tracking upstream, push to CVS and merging back

[Robert Widhopf-Fenk]

On Sunday, January 27, 2008 at 18:17:27, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Widhopf-Fenk wrote:
> > I have a project which uses BZR (viewmail) which is Upstream
> > and it is tracked in a larger project (xemacs packages)
> > using CVS, but eventually also CVS gets changes by its own.
> 
> Sorry for the delay.  It can be hard to find time to give such long
> messages the attention they deserve.

No need to be sorry, I was busy anyway and would have asked
again if no one answered ;-) ... and thanks for answering!

> > 1. Merge those changes from the xemacs package back to my
> >    upstream branch.
> 
> In general, changes should flow in one direction only, or else merge
> will tend to do things you don't want.

BZR has the best merge logic I used so far and advertises to
do just the right thing.

I am wondering what might go wrong?

> If you have "upstream", and you branch it to "package", then merging
> "package" back into "upstream" will apply all your packaging changes
> to upstream.
> 
> So when changes do happen in "package" that you want to apply to
> "upstream", you should cherrypick them.

This is also how others (with HG) seem to maintain their
packages, probably also for similar reasons.
 
> > BZR supports renames of files and directories, but I cannot
> > see how to express that all files from upstream "./lisp"
> > should be moved to xemacs-package "./".  I could move the
> > root of the BZR branch up by one directory r.w.to. the CVS
> > tree to handle this, but that does not look nice.  If I just
> > move the files, then new files in lisp/ will cause conflicts
> > and is adding the lisp/ directory also in the bzr-cvs branch.
> 
> Yes, that's not a good situation.  Bazaar doesn't have any way to
> represent the idea that two directories have merged, though.

It is a special case, I am not sure how often it occurs
... I never had it before ...

> > The next problem was that upstream and xemacs-package both
> > have a Makefile, but they are totally different.  While I
> > replaced the Makefile in the bzr-cvs branch, it still causes
> > merge conflicts and the new content from the upstream branch
> > gets added as Makefile.OTHER.  They have different file ids
> > and upstreams Makefile has been removed in the bzr-cvs
> > branch.  So why do I get a conflict?
> 
> Frequently, when someone changes a deleted file, it is a Very Bad
> Thing.
>    If someone is still using a file that you have deleted, there's
> probably a communication problem.
> 
> Or perhaps the contents of the file have moved elsewhere, and you
> need to apply the changes to a different file.  For example, if you
> have files "foo" and "bar", you could copy the contents of "bar"
> into "foo", and delete "bar".  But if someone changes "bar", then
> you would need to apply those changes to "foo".  Conflicts give you
> an opportunity to do that.
> 
> The point is that in any circumstances where Bazaar cannot apply
> changes, it will always conflict, so that you can apply them if
> appropriate.

Makes sense.

> 
> > I have expected that
> > those changes on the upstream Makefile just get ignored as
> > the original Makefile does not exist in the bzr-cvs branch
> > anymore.
> 
> There are many circumstances in which that would not be appropriate.
> Emitting conflicts is a conservative approach.
> 
> > (7) Merging bzr-cvs into upstream 
> > ---------------------------------
> > 
> > There are two options, either cherrypicks, or merging and
> > reverting the unwanted changes.
> > 
> > Cherrypicks are not tracked and there is also no way to tell
> > bzr that certain revisions are rejected, so IMHO I should go
> > for merge+revert+commit.
> 
> I don't agree.  If you cause the merge to be tracked, then you will
> be marking the changes in bzr-cvs as rejected, and if anyone ever
> merges your upstream into bzr-cvs, all of the packaging changes will
> be deleted.  Cherrypicking is The Right Thing here.

O.k. I'll follow your advice.

Many thanks,
Robert