I'm not sure if this actually helps reduce conflicts though.
doing a "dumb" conversion of existing round-tripped revisions won't help, since that means breaking referential integrity. bzr revids need to always point at the exact same revision; changing one of the revision parents breaks that: the parent of the tip would be changed from <email address hidden> to svn-v4:0487d25d-142b-0410-8fcf-b82ac621bf97:plugins/spice/branches/rails_2_2:50573.
to summarize: I agree this is a bit of a pain, but there was really no way the mapping upgrade given the limitations we had in bzr-svn 0.4.x. It'll be a while before there will be another mapping upgrade, and we should make sure we have the right support in place in merge/pull/push by then that you won't even notice.
yes, that would indeed remove the need for svn-upgrade.
you should be able to "downgrade" the trunk to v3 by pulling from svn and specifying an explicit older mapping revision id:
$ bzr pull -rrevid: svn-v3- trunk2: 0487d25d- 142b-0410- 8fcf-b82ac621bf 97:plugins% 2Fspice% 2Ftrunk: 53035
I'm not sure if this actually helps reduce conflicts though.
doing a "dumb" conversion of existing round-tripped revisions won't help, since that means breaking referential integrity. bzr revids need to always point at the exact same revision; changing one of the revision parents breaks that: the parent of the tip would be changed from <email address hidden> to svn-v4: 0487d25d- 142b-0410- 8fcf-b82ac621bf 97:plugins/ spice/branches/ rails_2_ 2:50573.
to summarize: I agree this is a bit of a pain, but there was really no way the mapping upgrade given the limitations we had in bzr-svn 0.4.x. It'll be a while before there will be another mapping upgrade, and we should make sure we have the right support in place in merge/pull/push by then that you won't even notice.