bzr-builddeb

merge-upstream fails when shared repository is present

Bug #264705 reported by James Westby
10
Affects Status Importance Assigned to Milestone
bzr-builddeb
Fix Released
Critical
Unassigned
bzr-builddeb 2.0.1

Bug Description

When the temporary upstream branch ends up in the same shared repository as the
main branch merge-upstream fails.

When calling fetch() to fetch the new upstream revision in to the packaging branch
the fetch code notices that they share the same repository, and just checks
that the revision is present in the repository.

This check is what fails, even though the revision is in the repository. It may
be that the list of packs in the repository needs to be refreshed in memory
or something.

modified PKG-INFO
modified setup.py
modified httplib2/__init__.py
added httplib2/iri2uri.py
Committed revision 2.
bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/jw2328/devel/launchpadlib/.bzr/repository/') has no revision <email address hidden>

Traceback (most recent call last):
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/commands.py", line 857, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/jw2328/.bazaar/plugins/builddeb/__init__.py", line 484, in run
    Version(version), current_version)
  File "/home/jw2328/.bazaar/plugins/builddeb/import_dsc.py", line 1942, in merge_upstream
    parents)
  File "/home/jw2328/.bazaar/plugins/builddeb/import_dsc.py", line 1528, in import_upstream
    self.branch.fetch(self.upstream_branch, last_revision=revid)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/branch.py", line 279, in fetch
    pb=nested_pb)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/repository.py", line 968, in fetch
    self.get_revision(revision_id)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/repofmt/knitrepo.py", line 222, in get_revision
    return self.get_revision_reconcile(revision_id)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/repository.py", line 1112, in get_revision_reconcile
    return self._get_revisions([revision_id])[0]
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/home/jw2328/devel/bzr/bzr.dev/bzrlib/repository.py", line 1130, in _get_revisions
    raise errors.NoSuchRevision(self, record.key[0])
NoSuchRevision: KnitPackRepository('file:///home/jw2328/devel/launchpadlib/.bzr/repository/') has no revision <email address hidden>

See original description

Related branches

lp:bzr-builddeb/2.0
James Westby (james-w)
Changed in bzr-builddeb:
importance: Undecided → High
milestone: none → 2.0.1
Revision history for this message
James Westby (james-w) wrote :

Bumping the importance to critical.

description: updated
Changed in bzr-builddeb:
importance: High → Critical
status: New → Confirmed
Revision history for this message
James Westby (james-w) wrote :

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

Changed in bzr-builddeb:
status: Confirmed → Triaged
Revision history for this message
James Westby (james-w) wrote :

Hi,

I have implemented (4) in my branch now.

Thanks,

James

Changed in bzr-builddeb:
status: Triaged → Fix Committed
James Westby (james-w)
Changed in bzr-builddeb:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.