tags are "permanently" propagated by merge

Bug #99137 reported by Christopher Armstrong
This bug affects 11 people
Affects Status Importance Assigned to Milestone

Bug Description

Usually, "bzr merge" can be thought of as an exploratory command. If you "bzr merge ../other" and don't like the result, you can "bzr revert", and there are effectively no changes to your branch (committed information). People who branch from you won't see the revisions (since we only copy ancestry), etc.

However, if the merge source includes any tags, those tags will be applied to your local Branch (such that they propagate to 3rd parties), without any sort of confirmation. Further, commands like "bzr revert" won't remove them from your Branch.

'bzr merge; bzr revert' also has the odd side effect that it can cause your Branch to start propagating a tag pointing to a revision which you don't have. If Joe merges Sue and reverts her change, he has her tag, but also her revision. However if he pushes his changes to Dave, he will propagate Sue's tag, without propagating Sue's revision.

It made more sense when tags were a "repository" property, but now that they are a "Branch" property, we may need them to also exist only in the working tree until a commit is made... (Maybe).

As an example:

radix@haruko ~/test% mkdir a
radix@haruko ~/test% cd a
radix@haruko ~/test/a% bzr init
radix@haruko ~/test/a% bzr commit --unchanged -m 'first rev'
Committed revision 1.
radix@haruko ~/test/a% cd ..
radix@haruko ~/test% bzr branch a b
Branched 1 revision(s).
radix@haruko ~/test% cd a
radix@haruko ~/test/a% bzr tags
radix@haruko ~/test/a% cd ../b
radix@haruko ~/test/b% bzr tags
radix@haruko ~/test/b% cd ../a
radix@haruko ~/test/a% bzr tag what
Created tag what.
radix@haruko ~/test/a% bzr commit --unchanged -m 'second rev'
Committed revision 2.
radix@haruko ~/test/a% cd ../b
radix@haruko ~/test/b% bzr merge ../a
All changes applied successfully.
radix@haruko ~/test/b% bzr st
pending merges:
  Christopher Armst... 2007-03-30 second rev
radix@haruko ~/test/b% bzr tags
what <email address hidden>
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what <email address hidden>

I posit that 'what' should gone after that revert.

Tags: tags
Revision history for this message
John A Meinel (jameinel) wrote :


Tags not a working tree operation. So 'revert' has no effect on them.

The local repository still has a copy of '<email address hidden>', so you could do
  bzr merge -r revid:<email address hidden>
or equivalently
  bzr merge -r tag:what

Supporting this would be tricky at best, because there are other ways to get tags. You can create a tag on an old revision (for example).

So if I tag revision -10 as "release-1.0". Which you already have (but I forgot to tag when I released).

And then you merge my tip because I've done more work. Do you want to not get that tag? Should "bzr revert" still remove the new tag (even though it is a tag on a revision in your current history)

If this is important to you, the best I can come up with is having merge track what tags are added (in a custom file) and then if you do "bzr revert" it will run "bzr tag --delete" for you.

Revision history for this message
Christopher Armstrong (radix) wrote :

That last thing you said sounds fine. The only thing I am concerned with is that

bzr merge x...
bzr revert

should leave my branch the way it was before those commands.

John A Meinel (jameinel)
Changed in bzr:
importance: Undecided → Wishlist
status: Unconfirmed → Confirmed
John A Meinel (jameinel)
description: updated
Revision history for this message
Martin Pool (mbp) wrote :

I'd say this is more than a wishlist; it is reasonable to expect that revert will undo the merge changes.

Changed in bzr:
importance: Wishlist → Medium
Revision history for this message
Martin Pool (mbp) wrote :

However, it is conceptually somewhat complex to fix, for the reasons John describes: tag operations take effect immediately, and are not subject to the normal commit/revert transaction.

description: updated
Revision history for this message
John Szakmeister (jszakmeister) wrote :

I'll add that myself and vila were a little surprised by this behavior too. And currently, the bzr-2.2b1 tag is pointing to a non-existent revision which is a bit odd.

Martin Pool (mbp)
tags: added: tags
Revision history for this message
Andrew Bennetts (spiv) wrote :

Note that this even happens if the branches are unrelated, as reported in bug 589514 (a dupe of this one).

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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