will propogate.
I.e. how does a commit of the results of bzr revert -r X differ from a
commit of the results of bzr merge -r -1..X?
Regards
Henrik
- the undo
will propogate.
I.e. how does a commit of the results of bzr revert -r X differ from a
commit of the results of bzr merge -r -1..X?
In current bzr, not at all.
In future, when the cherrypicking planned changes are made; bzr will
know
On Tue, 2008-03-25 at 10:34 +1300, Amos Jeffries wrote:
Robert Henrik,
Some of us have found a knowledge-hole in the bzr revert process.
We can easily reverse a patch using for example:
bzr revert -r 8902
But then when its fixed we don't know how to undo the undo.
The local
On Tue, 2008-03-25 at 10:34 +1300, Amos Jeffries wrote:
Robert Henrik,
Some of us have found a knowledge-hole in the bzr revert process.
We can easily reverse a patch using for example:
bzr revert -r 8902
I prefer using merge.
bzr merge -r 8903..8902
to undo revision 8903
On Tue, 2008-03-25 at 12:04 +1100, Robert Collins wrote:
'bzr revert' changes the working tree to be the same as a given revision
[with optional file list].
If you then do a commit - e.g:
bzr revert -r X
bzr commit
you are committing a changeset that happens to alter previously done
work
On Tue, 2008-03-25 at 13:04 +0100, Henrik Nordstrom wrote:
On Tue, 2008-03-25 at 12:04 +1100, Robert Collins wrote:
'bzr revert' changes the working tree to be the same as a given revision
[with optional file list].
If you then do a commit - e.g:
bzr revert -r X
bzr commit
you
Robert Henrik,
Some of us have found a knowledge-hole in the bzr revert process.
We can easily reverse a patch using for example:
bzr revert -r 8902
But then when its fixed we don't know how to undo the undo.
The local branch is left with code apparently up-to-date but is actually
