Semantics of bzr update

On 01/15/2012 02:50 PM, Uday Reddy wrote:
> New question #184785 on Bazaar:
> https://answers.launchpad.net/bzr/+question/184785
>
> I don't know if this counts as a bug. Revert to an older revision and then ask for an update. bzr says it is uptodate.
>
> Am I misinterpreting what bzr update is supposed to do?
>
> maruti[lisp]: bzr revert -r1333
> N lisp/vm-folder.el
> N lisp/vm-imap.el
> maruti[lisp]: bzr update
> Tree is up to date at revision 1336 of branch D:/gnu/vm/trunk
> maruti[lisp]: bzr version
> Bazaar (bzr) 2.1.0
> Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.4
> Python standard library: C:\Program Files\Bazaar\lib\library.zip
> Platform: Windows-XP-5.1.2600-SP3
> bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
> Bazaar configuration: C:\Documents and Settings\udr\Application Data\bazaar\2.0
> Bazaar log file: C:\Documents and Settings\udr\My Documents\.bzr.log
"bzr revert" changes only the working tree.

"bzr up" changes the branch.

In your case, you have reverted the state of the working tree, but not
that of the branch. So "bzr up" correctly doesn't do anything (the
branch is still on the last revision).

You probably want "bzr revert" (no arguments) in this case to get back
to the last tree /or/ you want to change both the branch and the working
tree back to r1333 by using "bzr up-r1333" rather than "bzr revert -r1333".

Cheers,

Jelmer

Sorry that I haven't monitored this question-answer session.

The manual says the meaning of `bzr update' is "Update a tree to have the latest code committed to its branch."

In the example, I gave the tree is at revision 1333. The branch is at revision 1336. I expected that `bzr update' would update the tree to revision 1336.

The reason I wanted to `bzr update' instead of `bzr revert' is that I had some changes in the working tree (not shown in this example) that I wanted to be merged with the revision 1336. The manual says that that is supposed to happen.

Aren't we looking at a bug here?

Cheers,
Uday

And what does `bzr diff -r1336` show?

Martin Pool writes:

> Martin Pool proposed the following answer:
> And what does `bzr diff -r1336` show?

It shows plenty of differences. Basically, `bzr update' did not do anything
to the working tree. The files in the working tree were still at revision
1333.

Cheers,
Uday

Thanks Martin Pool, that solved my question.

Yes, that makes sense. As Jelmer said in his first response, the primary purpose of `bzr update' is to update the branch, not the working tree. Merging those updates into the working tree is a "side effect", not the main purpose.

But the docs contradict this understanding. Even `bzr help update' that you pointed to says that the purpose of `bzr update' is to "Update a tree".

So, there is some double think going on in the docs.

It also seems that, for the application I had in mind, the following sequence of operations could have worked:

  bzr update -r1333
  ...make changes to the working tree
  bzr update -r1336

I am expecting that this would keep the changes in the working tree, and add to them the delta between 1333..1336. Am I right?

Cheers,
Uday

On 13 February 2012 20:41, Uday Reddy
<email address hidden> wrote:
> Question #184785 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/184785
>
> Uday Reddy posted a new comment:
> It also seems that, for the application I had in mind, the following
> sequence of operations could have worked:
>
>  bzr update -r1333
>  ...make changes to the working tree
>  bzr update -r1336
>
> I am expecting that this would keep the changes in the working tree, and
> add to them the delta between 1333..1336.  Am I right?

After that sequence, your uncommitted changes will be on top of the
changes from r1336. But I'm not sure what you're trying to
accomplish. If you want to replay the changes from 1333 to 1336, use
'bzr merge -r1333..1336' while on the tip of the branch.

--
Martin

Martin Pool writes:

> After that sequence, your uncommitted changes will be on top of the
> changes from r1336. But I'm not sure what you're trying to
> accomplish. If you want to replay the changes from 1333 to 1336, use
> 'bzr merge -r1333..1336' while on the tip of the branch.

Does bzr merge -r1333..1336 preserve the history of the revisions between
1333 and 1336? My experience is that merging a diff in bazaar loses
history.

Here are some scenarios where you might need this kind of thing:

- Working tree accidentally left at revision 1333, and you make
modifications to it. Then you are left with the problem of 'rebasing' those
changes to the latest revision.

- You might actually need an older revision to reproduce some behaviour and
you make a fix to it. Again a rebasing problem.

- You might want to manually backport changes from another branch that
diverged. You find the most convenient point in the history where
backporting is easy or safe, and then rebase those changes to the latest
revision.

I notice that all my examples are of rebasing variety. Update seems to give
a cheap form of rebasing.

Cheers,
Uday

On 15 February 2012 19:56, Uday Reddy
<email address hidden> wrote:
> Question #184785 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/184785
>
> Uday Reddy posted a new comment:
> Martin Pool writes:
>
>> After that sequence, your uncommitted changes will be on top of the
>> changes from r1336.  But I'm not sure what you're trying to
>> accomplish.  If you want to replay the changes from 1333 to 1336, use
>> 'bzr merge -r1333..1336' while on the tip of the branch.
>
> Does bzr merge -r1333..1336 preserve the history of the revisions between
> 1333 and 1336?  My experience is that merging a diff in bazaar loses
> history.
>
> Here are some scenarios where you might need this kind of thing:
>
> - Working tree accidentally left at revision 1333, and you make
> modifications to it.  Then you are left with the problem of 'rebasing' those
> changes to the latest revision.

yes, use update here.

> - You might actually need an older revision to reproduce some behaviour and
> you make a fix to it.  Again a rebasing problem.

here too.

>
> - You might want to manually backport changes from another branch that
> diverged.  You find the most convenient point in the history where
> backporting is easy or safe, and then rebase those changes to the latest
> revision.

here, either update, or merge, or bzr rebase (from the bzr-rewrite plugin.)
>
> I notice that all my examples are of rebasing variety.  Update seems to give
> a cheap form of rebasing.

true

--
Martin