bzr merges allow rewriting of commit ids
Closed this issue · 5 comments
a merge in bzr can be based on a branch but can be updated if the contents of the branch update, so that when looking at trunk the commit id of the merge will change while the revision number stays the same, confusing the hell out of the git mapping
a workaround right now is blowing away the mapping files and doing a git bzr sync to get your branch back up to date
Right, I though about this but did not came to trying to reproduce it.
Unfortunately "git bzr sync" takes about 3 hours here (66000+ changesets in bzr). And what will happen with the git branch if it already has some changesets? E.g. foo has some commits in addition to bzr/foo and then bzr/foo is sync'd?
Sorry, I mean that "git bzr sync --overwrite" takes ~3 hours
This is the same for git AFAIK in that a "branch" is an arbitrary pointer to a revision in either system. If the history of a branch changes, this is because it's HEAD pointer now points to a revision with a different history. This is not limited to merge revisions.
Bazaar does not arbitrarily rewrite revision histories, and unlike git, the default merge action is not to perform a fast-forward, so some special effort must have been made to achieve this situation (in the bzr branch) involving an uncommit or rebase command on a branch that was previously synced with git-bzr-ng.
A repository with 66,000 revisions must be quite old and sounds very much like it was converted from SVN, which IS something that encourages history rewrites (at least, in the branches you are keeping synced with SVN branches). Is this perchance a bzr repository that is still being used with a "live" SVN repo?
The real solution to this is not to rewrite history in branches that you have pushed to a common location - and any branch you are using for cross-VCS syncing counts as such a location. This applies to normal DVCS usage as well as cross-VCS usage.
If you are using multiple DVCS systems with a central VCS repository (ie - SVN) then I'm afraid that they should all use the central SVN repository as their source of "truth", especially when you are using using git-svn. bzr-svn is superior (IMHO) in this regard because two clients pulling the same SVN repository branches will end up with identical and interoperable bzr branches ; I'm not sure the same can be said about git-svn which I have so far found to be rather more complex to manage and less flexible.
Hello awilkins,
Sorry for my late reply.
I am talking about the MySQL bzr repository. It is not old nor it is converted from SVN. See https://launchpad.net/mysql-server/trunk
Currently using git-bzr-ng as a bi-directional bridge on the MySQL repo is not possible due to this issue.
Thanks!
haven't run into this in quite some time so i am closing it