How to handle 'tag pushing revisions' and stacking

[John Arbash Meinel]

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


...
> I think it's worth considering that if we want to support colocated
> branches in the future we will have to support a similar use case with
> multiple colocated branches instead of multiple tags. 

So the nice thing about branches, is they don't tend to live forever. I
know I have a bunch of branches around, but I don't have plans to
co-locate the 457 branches of bzr that I have registered on Launchpad.

It may not always be true, but I would guess that most colocated
branches will have similar lifetimes. Which is very different from
having the bzr-0.0.5 tag still around.

I would imagine that co-located branches might scale to ~50 branches or
so at best. (Beyond that, you have >1 screens full of branch names to
sift through to find the 'current' stuff.)

> 
> I think Vincent has a point that we could consider only looking at those
> tags that we are changing. We could add an option to have bzr push look
> really hard for missing revisions; this would also take care of another
> open bug about filling in ghosts during push if an option is specified.
> 
> Cheers,
> 
> Jelmer

ATM we don't know what tags we are changing at the appropriate levels.
It happens at very different locations. Consider that a stacked branch
doesn't *have* any tags yet. So we are changing all of them. (you could
arguably recurse to the stacked-on branch and only do the delta there,
but it isn't a trivial "what do I have that the target doesn't have".)

If we started versioning tags, that becomes a bit more straightforward,
but the same issue would apply to stacked branches.

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

iEYEARECAAYFAk2XbZcACgkQJdeBCYSNAAMk0wCgqvQtNxQ/4Xn/QIW7mbxCVy1b
ayAAnAxke4P7tuC9zfjVXAD0Eo2LmLgs
=GBZ1
-----END PGP SIGNATURE-----