Tracking upstream, push to CVS and merging back

[Aaron Bentley]

-----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.

> 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.

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.


> 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.

> 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.


> 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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHnREH0F+nu1YWqI0RAq4IAJ9oERFkK9rAtoiTcTP2TaYuXCF/ggCdFiih
bPRC3j55QJLNHNP+5Kk2hUM=
=b5k3
-----END PGP SIGNATURE-----