can't replay, need maptree support in rebase

[Jeff Fortin Tam]

I have 2 VCSes whose history I am trying to stitch together (cvs then svn). After managing to add 1 or 2 revisions to the cvs branch to make it match the contents of the svn one, I tried rebasing but it fails (it seems?), even though the contents are identical.

jeff@khloe:~/trunks/awesome-new-specto$ bzr branch specto-cvs-rrp-rebase_preparation/ specto-rebase
Branched 263 revision(s).
jeff@khloe:~/trunks/awesome-new-specto$ cd specto-rebase/
jeff@khloe:~/trunks/awesome-new-specto/specto-rebase$ bzr replay -r3.. ../specto-svn
Conflict adding files to data. Moved to root.
Conflict adding files to launch.sh. Moved to root.
Conflict adding files to po. Moved to root.
Conflict adding files to setup.py. Moved to root.
Conflict adding files to specto.desktop. Moved to root.
Conflict adding files to specto.png. Moved to root.
Conflict adding files to src. Moved to root.
Conflict adding files to src. Created directory.
Conflict because src is not versioned, but has versioned children. Versioned directory.
Conflict adding file src. Moved existing file to src.moved.
Conflict adding files to src/specto. Created directory.
Conflict because src/specto is not versioned, but has versioned children. Versioned directory.
Contents conflict in src/specto/main.py
Contents conflict in src/specto/watch.py
14 conflicts encountered.
bzr: ERROR: Working tree has conflicts.

<jelmer> nekohayo: the branches probably have different file ids
<nekohayo> jelmer: well, I assume so, they were different branches... what do I do?
<jelmer> the maptree stuff should be able to help there (it makes rebase/replay use paths rather than file ids) but that's not hooked up to the rebase ui yet (only used by svn-upgrade)
 so it's not really possible to use rebase/replay in this case
<nekohayo> >_<?! I don't exactly see what's so unusual with my case :|
<jelmer> different file ids
<nekohayo> jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids?
<jelmer> nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr. there's no way for historically not connected branches to have the same file ids
<nekohayo> so there's no way to go further now? solving the conflicts wouldn't do it?
<jelmer> nekohayo: you can use diff + patch manually to replay each commit so you end up using the file ids from the branch you're building on rather than the branch you're replaying
<nekohayo> basically recommitting everything by hand
<jelmer> yes
 I'm not aware of any bzr plugins at that can do that for you
 rebase/replay could do it if you hooked up the maptree stuff
<nekohayo> how hard is that?
<jelmer> should be a matter of adding a call to MapTree() in the function that replays a delta in rebase
<nekohayo> rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents,
 jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py
<nekohayo> but I don't understand it
<jelmer> nekohayo: you'd need the code in maptree.py
<jelmer> and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree()
<nekohayo> x_x beyond my skillset I guess... or is there a bug/blueprint I can subscribe to for rebase to support maptree?
<jelmer> no, though you could file one

Bazaar 1.5 from the PPA.

[Jelmer Vernooij (jelmer)]

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

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

iQCVAwUBSDBQXQy0JeEGD2blAQLNYQP9GIcdHWWYnWHkEUIYPYl2pfXGl+xpimZZ
4JATfxUdG8Q0qqcLGSNx4cYGd/d5PoeyloUTrjf7Uu5Y+P41aCJGPWEbys4on0mZ
rvkgIFMyhu1vvXK//bkni+Awv5e0s9w+1pCEz3qS4Hj3/6nXREIVJZQt2n5o49Ko
bwmh4P6UHBE=
=5ZED
-----END PGP SIGNATURE-----

[Jelmer Vernooij (jelmer)]

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

  affects bzr-rebase
  status triaged
  importance wishlist

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

iQCVAwUBSDBVDQy0JeEGD2blAQIL0gP+LX01HCA8sUedat9skNpVbPWJyDRzrE80
N+xqykuPUJ0mBvoFha3OkXVVWV4XeLNVRcIou00/h/bC5629NHyXzdGQ1QVO+8dY
gDSCs3JU1ZTcJMGAZqCrDQOfhX7zJ2UuIIMugipAh5OIziAHKHPl9OPVydoz2+ei
Z8tHG1A9DFU=
=1l8w
-----END PGP SIGNATURE-----

[Matt Giuca (mgiuca)]

I find that replay works if:
a) It is the first revision (it adds all the files in the first revision fine), OR
b) No files are added, only changes made to files.

For example, if I have a branch with 3 revisions:
Revision 1:
added:
  bar
  world

Revision 2:
modified:
  world

Revision 3:
added:
  cat

I take a second, empty branch (I have to make 1 commit just to give it a root), and do
$ bzr replay -r1 ../other_branch/
added bar
added world
Committed revision 2.
$ bzr replay -r2 ../other_branch/
modified world
Committed revision 3.
$ bzr replay -r3 ../other_branch/
Conflict adding files to cat. Moved to root.
1 conflicts encountered.

It seems strange that it is only encountering problems adding files. Just thought I'd point that out.

[Tymek (maju7)]

>I find that replay works if:
>a) It is the first revision (it adds all the files in the first revision fine), OR
>b) No files are added, only changes made to files

I added https://bugs.launchpad.net/bzr/+bug/436559 (Adding a file+Merging resutls in "Conflict adding files to FILE_NAME_HERE. Moved to root.")
and my findings are more less the same as Matt Giuca's (but I'm just trying to do a merge):