Tracking upstream, push to CVS and merging back

[Robert Widhopf-Fenk]

Hi,

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.

Currently Upstream is tracked by hand, but this is tedious
once you got used to proper merge support, so I was looking
for an easier way.

How do others solve this?

After some discussion with other package maintainers I thought
will try it as follows.

1. Merge those changes from the xemacs package back to my
   upstream branch.
2. bzr-branch upstream into the xemacs package CVS
   directory, I will call it bzr-cvs branch.
3. Move and delete files in bzr-cvs according to the xemacs
   package CVS directory.  Files used in both branches, but
   that do not correspond to each other, will be handled by
   removing them and adding the CVS original as new file to
   bzr-cvs.
4. If CVS shows no changes, then bzr commit. Now BZR and CVS
   should be in sync and merging can start. 
5. A pull/merge from upstream should be easy, still I will
   have to manually update ChangeLog, Makefile and the like,
   but there is no way to avoid this and thus also the cvs
   commit should be manually.
6. Cvs update in the bzr-cvs branch and then bzr commit the
   changes to incorporate changes in CVS to bzr-cvs.
7. Merging from bzr-cvs to upstream either by cherry picking
   or merge+revert. 

(1-5) Merge from upstream to bzr-cvs 
------------------------------------

Now after trying 1-5 for a simple test project I found some
problems.

Upstream and xemacs-package have a different directory layout.

Upstream looks like this
     ./lisp/*.el
     ./info/*.texinfo
     ./README
     ./Makefile
xemacs-package looks like this
     ./*.el
     ./.txinfo
     ./Makefile (but a different one than upstream)

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.

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

The result looks like this ...

> bzr st
added:
  Makefile.OTHER
  lisp/
  lisp/b.el
modified:
  a.el
unknown:
  Makefile.BASE
conflicts:
  Contents conflict in Makefile
  Conflict adding files to lisp.  Created directory.
  Conflict because lisp is not versioned, but has versioned children.  Versioned directory.
pending merges:
  ...
  
(6) Merging CVS changes into bzr-cvs
------------------------------------

Sharing the log messages and patch sets would be great, but
I am not sure how to do it.

Tailor seems to be no option.  I could use it to track CVS,
but it would result in a bzr branch with different file ids
and how could I merge it then?  Well there is the "fileid"
plugin, but it seems to be outdated and a hack.

I also have some crappy code to somehow sync bzr and CVS (by
cvsps), but well it is crappy.

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

Is it better to merge+commit and then revert+commit or is it
o.k. to do it in one step, i.e. merge+revert+commit.

Thanks,
Robert.