| 2007-03-30 20:11:15 |
John A Meinel |
description |
radix@haruko ~/test% mkdir a
radix@haruko ~/test% cd a
radix@haruko ~/test/a% bzr init --format=dirstate-tags
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 radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
I posit that 'what' should gone after that revert. |
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 --format=dirstate-tags
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 radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
I posit that 'what' should gone after that revert. |
|
| 2009-09-30 01:29:08 |
Robert Collins |
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 --format=dirstate-tags
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 radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
I posit that 'what' should gone after that revert. |
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 radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what radix@twistedmatrix.com-20070330191100-7b8idcrh27w6l4tl
I posit that 'what' should gone after that revert.
|
|
