How to handle 'tag pushing revisions' and stacking

[vila]

>>>>> John Arbash Meinel <john at arbash-meinel.com> writes:

<snip/>

    > 2) The second push sees "hey you have a branch there, do you have
    > all the revisions for all of your tags"? And then proceeds to
    > upload a revision for every tag. It then follows that up by
    > pushing the inventories for the parent of every tag you have.

    > 3) Third and subsequent pushes don't push up new content, but *do*
    > issue a 'get_parent_map' check on the set of tags that you have,
    > because they are checking if any of them need to be uploaded.

Wouldn't it be sufficient to check which tags are present remotely and
assume their revisions have already been pushed ? Or are we catching up
with an old bug here ?

<snip/>

    > There are some real performance and amount-of-data transferred issues.
    > bzr isn't a very large tree, and has about 151 tags. My 'second push'
    > case cost 1.2MB of transfer to copy up the revisions (and their
    > associated parent revision inventories) for the tags referenced in bzr.
    > (Note that it is always the *complete* inventory for all parents, modulo
    > shared chk pages. However, tags age, our oldest tag in bzr is about
    > 2006, and there aren't many shared chk pages from 2006 to 2011.)

    > Emacs has 1129 tags, and the oldest is from 1995 (and there are a lot
    > from 1995). Right now, every stacked branch will end up transferring a
    > whole lot of extra content. And even if we fix that, they still use a
    > lot of bandwidth to check if the revisions are present.

    > Thoughts?

This is serious enough to consider disabling the offending change.

But we need to fix it anyway so the question is more what are the
releases impacted here (2.3.1 ?) and when will we release a fix for this
bug and what are the possible fixes/workarounds.

        Vincent