Problems with deleting tags?

Richard Wilbur richard.wilbur at gmail.com
Mon Apr 25 16:30:52 UTC 2016


On Wed, Apr 20, 2016 at 11:47 AM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>>>>>> Richard Wilbur <richard.wilbur at gmail.com> writes:
>
>     > On Mon, Apr 18, 2016 at 3:20 AM, Matthew D. Fuller
>     > <fullermd at over-yonder.net> wrote:
[...]
>     > Interestingly, as of bzr 2.7.0, the identity and date/time of
>     > the tag creator is stored in .bzr/branch/tags
>
> Precision, tags is really only a dict name -> revid.
>
> The revid often embeds the committer email and a timestamp but that's not
> a requirement and cannot be relied upon nor extracted from the revid.
>
> I.e. identity and timestamp are not stored in tags file, the revid is,
> and the revid is an opaque token.

Somehow this is an excerpt of what I'm seeing in my bzr 2.7.0 source
tree .bzr/branch/tags:

$ cat .bzr/branch/tags
d8:0.11-1.158:larstiq at larstiq.dyndns.org-20061227002500-vvz6cqr8i7796cw38:0.13-0.158:larstiq at larstiq.dyndns.org-20061229011453-tlyyrbu3xrcw3jlj6:0.14-158:larstiq at larstiq.dyndns.org-20070126001040-cahjcf62nw6pmth46:0.15-158:larstiq at larstiq.dyndns.org-20070406230348-ug09r0ehklq3x0lb6:0.16-151:siretart at tauware.de-20070509163020-xkei88ocnpnpdex36:0.17-151:siretart at tauware.de-20070618102821-tqmn3xcikqsb1gz210:0.17~rc1-151:dato at net.com.org.es-20070612161126-rsdteujhy3r3u3296:[...]

Looks like there is an initial code "d8" followed by pairs
:<tag name>:<revision>

where <revision> looks like
<E-mail address>-<date and time stamp>-<revid>

This pattern is consistent in this file from the earliest tag
"bzr-0.0.550" by mbp at sourcefrog.net on 20050615060316
to the latest tag
"bzr-2.6.052" by v.ladeuil+lp at free.fr on 20130727112434

I parsed and processed the file using:
cat .bzr/branch/tags | sed 's/:\([^:]*:[^:]*\)/\n\1/g' | grep ':' |
sed 's/\([^:]*\):\([^@]*@[^\.]*\.[^-]*\)-\([0-9]\{14\}\)-\(.*\)/\1 \2
\3 \4/' | sort -k3,3

The first sed puts each tag on its own line.  The grep discards the
initial 'd8'.  The second sed replaces ':' and '-' delimiters with
<space>.  Finally, sort by date/time stamp.

bzr-0.0.550 mbp at sourcefrog.net 20050615060316 97b948fb1eade31f7
bzr-0.150 mbp at sourcefrog.net 20051013032322 dc469f4b81f8e7f98
[...]
bzr-2.6b252 v.ladeuil+lp at free.fr 20120710093645 0hxiuu6t4sw3yh0e17
bzr-2.6.052 v.ladeuil+lp at free.fr 20130727112434 nlka3zj5j6bbl1iy9

>     > It looks like making the tag creation an integral part of the commit
>     > operation was proposed but, as far as I can tell, left unimplemented
>     > in bzr.
>
> Yes, because the main use case is to tag /after/ the commit, it may be
> months after the commit.

Well that sounds like as good a reason as any to not worry about
implementing tag creation during commit!

> The issue I have with handling the tag history as part of the branch
> history is that it really is a different history than the code one.

I think I understand what you are saying.  On the other hand, aren't
the revision ids relatively meaningless outside the context of a
branch containing the referenced revisions?

> The tags history is about the tags, whether or not I did commits on the
> branch is in a different dimension ;)
>
> If I can pull/push/merge the tag history, then propagating tags or not
> become tractable.

So do I understand you correctly that you would prefer to be able to
handle the tag history separately from the source?  One command to
pull the source branch, another to pull the tags, so that every
manipulation of the tags is explicit?  That would solve some problems
inadvertently raised by the current behaviour of tags in the
situations you mention below.

Thank you for several representative use cases!  My understanding
appears inline.

> For example:
>
> As a dev, I will push my code commits and generally pull the tag
> history.

So developers will pull the initial code and tag history and normally
only want to push code commits--not tags.  Most developer-created tags
are only of local interest and would therefore likely pollute the
public tag namespace on public branches.  If a developer wants to grab
new changes (including tags) from a public branch, he would prefer to
merge in the upstream changes rather than lose any local tags he has
created.

> As a release manager, I pull the code history but I push the tag one.

When making a release, the release manager needs to pull the code,
test, tag (public), package, and test the packaged result.  Sometimes
followed by changes to the code or packaging followed by moving the
tag.  Then changes (mostly to tags) need to be pushed back into the
public branch.

> As a distro packager, I pull code and tags from upstream and push both
> (downstream). I may also push code upstream, but never tags.

When packaging a distribution, the packager pulls the code and tags,
tests with the rest of the distribution, fixes bugs that surface
during testing, pushes code and tags down into the distribution
repository with package details, and may push bug fixes (but not tags)
back up into the public branch.

> If a dev push local tags in a merge proposal, this can be fixed at
> review time or ultimately fixed by the release manager.

We could even automatically flag changes to the tags in a merge
proposal.  (Do they currently show up in the diff?)

> What we have right now (including the --overwrite-tags to close the
> loop) is a way to maintain a set of tags for a branch.
>
> No history.
>
> But no cluttered UI either and we cover all but the rare edge cases.

Agreed.  If we could cover the recurring edge cases so that it "Just
Works!", without cluttering the UI, that would be even more
satisfying.

> Yes, tag history is nice, but not worth the cost of a migration
> (including annoyed users ;)

I agree.

> On the other hand, we have a plugin architecture so exploring these
> ideas is perfectly doable without a format change (not to mention
> feature flags
> http://doc.bazaar.canonical.com/bzr.dev/en/whats-new/whats-new-in-2.5.html#feature-flags
> ).

This sounds very interesting!  I've got some reading to do. ;>)

> And that plugin could even address ckalisiak issue whereas a new bzr
> won't until a windows installer is built.

That brings up two issues:
1.  I need to learn more about plugins to understand how a plugin can
affect the behaviour of push, pull, merge, tag, tags, etc.
2.  I'd like to establish what it takes to build a new windows
installer.  Can it be done using a toolchain that is available gratis?
 (I currently have no other reason to purchase, install, or maintain a
windows build environment.)

> That doesn't mean such a plugin couldn't be merge in core ultimately.

A fine goal.

Vincent, thank you for helping shape the discussion.



More information about the bazaar mailing list