tags are copied but their revisions may not be

Aside from the missing revision, if bzr tags can handle a missing tag gracefully (with a simple ?), then should other operations too.. Tracebacks are never a UI win..

This would be an issue with Bazaar core as well.

I have the same:

Got some more:

thom@thom-desktop:~/dev$ bzr upload ftp://***@gangas.nl/private/temp
FTP ***@gangas.nl password:
bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/thom/dev/.bzr/repository/') has no revision ('thom@thom-desktop-20090321152445-9xye1pjxpc8xcgnn',)

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/plugins/upload/__init__.py", line 123, in run
    self.upload_tree()
  File "/usr/lib/python2.5/site-packages/bzrlib/plugins/upload/__init__.py", line 259, in upload_tree
    from_tree = self.branch.repository.revision_tree(rev_id)
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1663, in revision_tree
    inv = self.get_revision_inventory(revision_id)
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1627, in get_revision_inventory
    return self.get_inventory(revision_id)
  File "/usr/lib/python2.5/site-packages/bzrlib/decorators.py", line 138, in read_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1520, in get_inventory
    return self.iter_inventories([revision_id]).next()
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1538, in _iter_inventories
    for text, revision_id in self._iter_inventory_xmls(revision_ids):
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1549, in _iter_inventory_xmls
    raise errors.NoSuchRevision(self, record.key)
NoSuchRevision: KnitPackRepository('file:///home/thom/dev/.bzr/repository/') has no revision ('thom@thom-desktop-20090321152445-9xye1pjxpc8xcgnn',)

bzr 1.6.1 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'upload', 'ftp://<email address hidden>/private/temp']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'nl_NL.UTF-8'
plugins:
  avahi /usr/lib/python2.5/site-packages/bzrlib/plugins/avahi [0.3.0dev0]
  bzrtools /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools [1.6.0]
  dbus /usr/lib/python2.5/site-packages/bzrlib/plugins/dbus [unknown]
  email /usr/lib/python2.5/site-packages/bzrlib/plugins/email [unknown]
  gtk /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk [0.95.0]
  launchpad /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
  pqm /usr/lib/python2.5/site-packages/bzrlib/plugins/pqm [1.0.0dev0]
  r...

On Sat, 2009-03-21 at 15:44 +0000, thom wrote:
> I have the same:

Please file a new bug - you don't have a similar backtrace, nor do you
appear to be using tags.

Thanks!

-Rob

just to confirm, a simple test case is:

bzr init branch1
bzr commit --unchanged branch1 -m "1"
bzr branch branch1 branch2
bzr commit --unchanged branch1 -m "2"
bzr tag -d branch1 b1-2
cd branch2
bzr merge ../branch1
bzr revert
bzr tags # shows b1-2 ?
bzr diff -c tag:b1-2 # works
cd ..
bzr branch branch2 branch3
cd branch3
bzr tags # Shows b1-2 ?
bzr diff -c tag:b1-2 # fails

The tag was copied into 'branch2' by the merge operation, but because we reverted that merge, we did not keep the revision in the ancestry. When we then create branch3, it also copies the tag information, but it does not copy the revision.

This bug is affecting code in bzr-builddeb which uses tags to track upstream tarballs - we should fix this (IMO to copy the tagged revisions).

On Tue, 04 May 2010 02:27:24 -0000, Robert Collins <email address hidden> wrote:
> This bug is affecting code in bzr-builddeb which uses tags to track
> upstream tarballs - we should fix this (IMO to copy the tagged
> revisions).

In normal use the tags should reference revisions in the revision
history of the tip, so this shouldn't be a problem unless an alternative
structure is created.

Thanks,

James

What's the value in copying (tagged) revisions into a branch if they aren't reachable from the head? Wouldn't it be equally sensible to drop the tag from the branch when cloning it (and ignore it when displaying it)?

I guess there's a performance cost to pay when checking the integrity of the tag data. In that case, maybe that validation could be done by check (and fixed by reconcile)?

A tag that isn't reachable from head is just a tag that isn't
reachable from head. Its very valuable; it shows something the user
chose to tag. Discarding that data and losing it forever is very
unfriendly, and there is not particular reason that copying them
around should be expensive.

It seems to me that copying all the revisions for which we have tags, even if they are not in the ancestry of the branch tip is the right thing to do. If that means fetching too many revisions then the user can always remove some of those tags.

This is only marked low priority, but I think it's also relatively easy to fix, so I'm going to do it.

This has now landed in lp:bzr, and will be part of bzr 2.4.

It turned out to be a little more involved than I anticipated, but happily some nice optimizations and refactorings fell out of this work :)

The landed fix copies tagged revisions along with tags as part of 'bzr branch', 'bzr pull' and 'bzr merge'. Apparently 'bzr join' still doesn't copy tags; that's bug 693533. If you encounter any other cases that don't copy tags but should, please file bugs about them!

It could be good (and maybe now even easy) to fix https://bugs.launchpad.net/bzr/+bug/401646 here too: also unstack things referenced by tags.

bzr-svn (and probably other plugins) still needs fixing. At a glance for 'bzr pull' InterSvnOtherBranch's _update_revisions needs an equivalent fix to bzrlib (consider the tags as well as the tip).

This is fairly tricky to do efficiently with Mercurial; Mercurial itself just hides tags that point at revisions not in the tip ancestry.

We only find out the tags at the point that the tip contents have been fetched, so we'd have to do completely new pulls for the revisions that are missing.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/30/2011 4:01 PM, Jelmer Vernooij wrote:
> This is fairly tricky to do efficiently with Mercurial; Mercurial itself
> just hides tags that point at revisions not in the tip ancestry.
>
> We only find out the tags at the point that the tip contents have been
> fetched, so we'd have to do completely new pulls for the revisions that
> are missing.
>
> ** Changed in: bzr-hg
> Milestone: 0.2 => None
>

It seems like you could just do an elongated fetch. So you first fetch
the current tip, then after you have it, you see what other data you
need, and send that along.

Certainly we already do that in bzr for fetching inventories chaining to
chk_bytes chaining to file texts.

I don't know the bzr-hg internals, but conceptually it doesn't seem like
we would have to know all the tags up front.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2TPT0ACgkQJdeBCYSNAANa9gCdHbs29wakwdu/TZWgFIplRVTp
fa8AoJypSNz7baewpQfLFh/KniYyW0s6
=q+pY
-----END PGP SIGNATURE-----

On Wed, 2011-03-30 at 14:25 +0000, John A Meinel wrote:
> On 3/30/2011 4:01 PM, Jelmer Vernooij wrote:
> > This is fairly tricky to do efficiently with Mercurial; Mercurial itself
> > just hides tags that point at revisions not in the tip ancestry.
> >
> > We only find out the tags at the point that the tip contents have been
> > fetched, so we'd have to do completely new pulls for the revisions that
> > are missing.
> >
> > ** Changed in: bzr-hg
> > Milestone: 0.2 => None
> >
>
> It seems like you could just do an elongated fetch. So you first fetch
> the current tip, then after you have it, you see what other data you
> need, and send that along.
>
> Certainly we already do that in bzr for fetching inventories chaining to
> chk_bytes chaining to file texts.
>
> I don't know the bzr-hg internals, but conceptually it doesn't seem like
> we would have to know all the tags up front.
It's trivial to do it like that, it's doing it in a way that doesn't
hurt performance that worries me. Doing a second fetch requires new
analysis of what revisions are present locally versus remotely and it
might require a new http connection to be opened.

If there is a tag that points at a ghost remotely then each fetch from
the remote host will require an extra graph inspection and fetch we
don't do at the moment.

Cheers,

Jelmer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I don't know the bzr-hg internals, but conceptually it doesn't seem like
>> we would have to know all the tags up front.
> It's trivial to do it like that, it's doing it in a way that doesn't
> hurt performance that worries me. Doing a second fetch requires new
> analysis of what revisions are present locally versus remotely and it
> might require a new http connection to be opened.
>
> If there is a tag that points at a ghost remotely then each fetch from
> the remote host will require an extra graph inspection and fetch we
> don't do at the moment.
>
> Cheers,
>
> Jelmer
>

Except hg can't have ghosts...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2UBxwACgkQJdeBCYSNAAP6lgCguZhF6+NP6jwM/aGHnNFipZZg
pNgAoItbHjf3jiv2CW/FhbjjqnFkI0l2
=NGEH
-----END PGP SIGNATURE-----

On Thu, 2011-03-31 at 04:46 +0000, John A Meinel wrote:
> > I don't know the bzr-hg internals, but conceptually it doesn't seem like
> >> we would have to know all the tags up front.
> > It's trivial to do it like that, it's doing it in a way that doesn't
> > hurt performance that worries me. Doing a second fetch requires new
> > analysis of what revisions are present locally versus remotely and it
> > might require a new http connection to be opened.
> >
> > If there is a tag that points at a ghost remotely then each fetch from
> > the remote host will require an extra graph inspection and fetch we
> > don't do at the moment.
> Except hg can't have ghosts...
I mean ghosts as in tags that reference revisions that are not present,
which it will deal with just fine (and which can be created if there are
tags for revisions not in the tips ancestry)

Cheers,

Jelmer