Comment 2 for bug 264705

Thanks to Robert I now understand this problem much better.

A write lock is taken out on both branches, and when the commit
is done to one this new revision won't be visible in the repository
of the other until it is unlocked and locked again.

There are 4 classes of solutions.

  1) Don't do write operations in two branches at once. The first step would
      commit the new upstream, and then the second would merge it. I don't
      like this, as there is no reason for them to be separate, users will question
      why the tool can't just do the operation if it tells them exactly what to run,
      and there will be more temptation to mess with the upstream branch if
      it is exposed like this.

  2) Add some sort of refresh method to bzr so that the repository can be
      refreshed without unlocking.

  3) Don't lock the packaging branch until later. This will mean that we have
      to do a lot of work before we can do something simple like error if there
      are uncommitted changes. Also, since we need to look up the last version
      from the changelog before we can extract the upstream branch this may
      not even be possible in a non-racy way.

  4) Unlock and lock the branch, checking that there were no modifications done
      in the time when it was unlocked. The user may get a strange error if they do
      hit the race, but it should be rare.

4 is probably the best alternative to explore at the moment.

Thanks,

James