Code: Select all
# fetch 0.4 bzr branch lp:armagetronad/0.4 || exit # get first revision bzr branch 0.4 0.4_first -r 1 || exit rm -rf 0.4_first/.bzr -rf || exit # prepare shared repository mkdir import || exit pushd import || exit bzr init-repo . || exit # fetch 0.2.8 into repository so all its revisions are prepared bzr branch lp:armagetronad/0.2.8 || exit mv 0.2.8 0.2.8_raw || exit mkdir 0.2.8 || exit pushd 0.2.8 || exit # reproduce the state at the start of 0.4 cp -ax ../0.2.8_raw/.bzr . || exit cp -ax ../../0.4_first/. . || exit bzr add || exit #bzr status bzr commit -m "First merge from 0.4" || exit # export bzr fast-export --export-marks=../../marks_0.2.8 > ../../0.2.8.fi || exit # fake previous aborted fastimport that produced precisely the good 0.2.8 branch sed -e s,^:,, < ../../marks_0.2.8 > ../.bzr/repository/fastimport-id-map # back to root popd || exit popd || exit cp marks_0.2.8 marks # branch last good revision bzr branch 0.4 0.4_stitched -r 795 || exit # stitch merge: merge broken revision, but just the content. pushd 0.4_stitched || exit bzr merge ../0.4 -r 796 || exit # forget merge details bzr revert --forget-merges || exit bzr commit -m "Re-doing merge of utf8 branch, forgetting about broken details" # export the history up to that point, storing marks bzr fast-export -r 2.. --marks=../marks > ../0.4_stitched_1.fi || exit # switch to full branch popd || exit pushd 0.4 || exit # export rest of history, taking care not to recycle old marks bzr fast-export --import-marks=../marks -r 796.. >> ../0.4_stitched_2.fi || exit # create import popd || exit # merge imports cat 0.2.8.fi 0.4_stitched_1.fi 0.4_stitched_2.fi > import.fi pushd import || exit bzr fast-import ../import.fi || exit popd
Compiles almost fine, the build just complains about a missing configuration file.
The basic idea here is that bzr-fastimport is tricked into recreating the history 0.2.8 exactly; this is done by writing the file import/.bzr/repository/fastimport-id-map . In that file, bzr-fastimport usually stores which revision number from the fastimport file corresponds to which revision ID in the shared repository after it imports them. The intention is that you can redo a fastimport and get the same result as before, and faster than a full reimport.
Well, and bzr-fastexport supports storing a very similar mat of revision numbers to revision ids for the purpose of mashing unrelated exports together. We just take that, convert it and plug it into the other thing.
The history of the full branch consists of three sections and two stitching commits:
First, the exact copy of 0.2.8's history. Goes from 1 to 1452 in this first attempt.
Then, revision 1523 crudely overwrites the last state of 0.2.8 with the initial state of 0.4. The ugly bit is that this state is from an earlier time and removes features and bugfixes.
From there to revision 2246, it follows the history of 0.4 until the broken bit.
Revision 2247 is the broken merge, redone as flat merge.
The rest is then the rest of 0.4's history.
As before, merging with regular 0.4 and svn won't work. But now at least technically, merging from 0.2.8 works. I write 'technically' because the reverting back to the start of 0.4 and then replaying all the changes, including merges from 0.2.8, means that many changes from 0.2.8 happen in this branch, get undone and then happen again. This is bound to cause conflicts if the same changed code lines change again. Maybe it helps if we hide away (not destroy) all of 0.4's history with a collapsing merge:
Code: Select all
bzr pull -r 1452 --overwrite bzr merge bzr commit -m "merge from 0.4"
Import to git should work smoothly from there.