Comment 31 for bug 485601

Was also struck by this.

Where M1 is my desktop and M2 is my laptop

M1 :
  merged some changes from bzr topic branch into SVN trunk
  pushed these to SVN

# somewhat later
M2 :
  pulled this merged revision from SVN
  also pulled some later revisions committed to SVN by other SVN clients

M1 :
  attempt to pull branch from M2
  error occurs

M1 :
  in attempt to fix missing ghosts, tried push --overwrite of this branch to M2 (over bzr:// smart server)
  this does not fix the problem ; presumably M2 just reports that it already has the tip revision and nothing actually happens
  would this work if you tried over file:// ?

Resolution :
M2 :
  delete repository
  create new empty repository
M1 :
  push SVN trunk branch to M2 repository
M2 :
  pull new SVN revisions
  # only M2 has access to SVN at the moment because the VPN concentrator is prejudiced against non-Windows VPN clients
M1 :
  pull new SVN revisions from bzr branch on M2
  success!

I can imagine that where multiple persons are merging and then pushing to SVN, this would be a real showstopper.

You should be able to prevent this by only pushing Bazaar revisions to SVN from one machine, or by using rebase exclusively. This has not happened to my colleagues who only use rebase. It might be simplest to set up a bzr repository on the SVN server that pulls desired SVN branches via SVN post_commit hooks and pushes back any revisions it receives to these branches.

Would a command to deliberately lock a bzr branch assist this use case? Some SVN commits can be quite prolonged and it would be annoying to push a revision, only to discover it had then been overwritten by a pull from the SVN branch (--overwrite being pretty much a given, since you cannot rewrite SVN history). The lock command could be issued by the SVN pre-commit hook, then released before the post-commit pull. Although a quick and dirty echo of a lock file might work.

Bazaar (bzr) 2.3.1 bzr-svn 1.0.5dev # standard Natty packages