update command cannot take a revision number

Nicholas Allen wrote:
> Public bug reported:
>
> bzr update cannot take a revision number so that I can update my working
> tree to a particular revision. It will only update to the latest
> revision. This is useful if you commit something and then want to go
> back to a previous revision (e.g. to check if a bug exists there or
> not). You could do a fresh checkout into a different directory but that
> is not very convenient. bzr should play back the revision history in
> reverse in order to update to a previous revision. This way only
> modified files are touched and things like make will only rebuild the
> modified files.
>
> ** Affects: bzr (upstream)
> Severity: Normal
> Priority: (none set)
> Status: Unconfirmed
>

You can just use 'bzr revert -r revno' or 'bzr uncommit -r revno' if you
 are going back in history.

John
=:->

That's good to know. However, if I revert to an older revision and then use revert -r to a new revision I get conflicts. It doesn't work quite how I expected. In svn I can svn update -r and can move my working copy between any revisions. It also does not seem very intuitive have the -r on revert to me. revert is for reverting your local changes that have not been committed. Update seems like the more appropriate command for the -r option - and I think it should allow you to move back and forth through revision history like svn does.

On Sun, 2006-05-21 at 12:14 +0000, Nicholas Allen wrote:
> That's good to know. However, if I revert to an older revision and then
> use revert -r to a new revision I get conflicts. It doesn't work quite
> how I expected. In svn I can svn update -r and can move my working copy
> between any revisions. It also does not seem very intuitive have the -r
> on revert to me. revert is for reverting your local changes that have
> not been committed. Update seems like the more appropriate command for
> the -r option - and I think it should allow you to move back and forth
> through revision history like svn does.

Agreed. Update and revert are quite different in intent, and update
should have a -r option.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

I was surprised to see that svn revert does *not* accept a -r parameter. Actually I remember being annoyed by this in the past - if you want to roll back to a previous text you must do so through svn cat or merge.

On Tue, 2006-05-23 at 05:13 +0000, Martin Pool wrote:
> I was surprised to see that svn revert does *not* accept a -r parameter.
> Actually I remember being annoyed by this in the past - if you want to
> roll back to a previous text you must do so through svn cat or merge.

svn update -r revision

Because svn revision numbers are not tree wide, it has a less strict
separation between revert and update.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

An implementation together with testcases is available here:

http://www-verimag.imag.fr/~moy/bzr/bzr/bzr.update-r/

Confirmed on the mailing-list.

Mattheiu Moy has a pending fix for this.

The fix is available, but needs some cleanup

The patch is still waiting in the queue to be properly reviewed for 0.13.

We need this feature for a Bazaar fetcher in BitBake, where this is common: At the moment when a newer revision is required, we have to delete the entire checkout and re-fetch it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Burton wrote:
> We need this feature for a Bazaar fetcher in BitBake, where this is
> common: At the moment when a newer revision is required, we have to
> delete the entire checkout and re-fetch it.

Some work was done on this, but it didn't meet Bazaar's quality
standards and the patch was abandoned by its author. It can be found here:

http://bundlebuggy.aaronbentley.com/download_patch/%<email address hidden>%3E

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3ZdX0F+nu1YWqI0RAlZTAJ4uKRhWZSiAqZ8VYzxOQQmKFVygkQCdHTYE
a8vCL46kLo9if4HGq6p6IHM=
=5dc0
-----END PGP SIGNATURE-----

I just went to report this same issue, and found this issue reported 2 years ago. FWIW, there is still a demand for this, and it would be great to see this in bzr 1.x. =)

For an example of why this is expected by users:
cvs up -rREV
svn up -rREV
hg up -rREV
bzr up -rREV <-- only one that doesn't work. =(

I think this bug is the same as #183559, only the latter more accurately describes the required syntax in terms of "switch" rather than "update", IMHO (take a look at it).

This would be a great feature to have added to the next version of bzr. I just ran into the need for it myself, because I am trying to hunt down a bug in a near-unmaintainable code base, and using "update -r REV_I_THINK_DID_NOT_HAVE_BUG" would be very useful to try to isolate it, find the change that broke it, and fix it. What was wrong with the patch above, exactly?

@Miguel: They are not dupes because this is for update and bug 183559 is for switch. Unless they use the same code, that is, which I haven't looked into.

@Michael: My point is that bug 183559 and this bug discuss the same missing feature, but this missing feature would be better implemented as part of the "switch" command than as part of the "update" command. The reason why "update" sounds more natural is that other revision systems perform the equivalent of "bzr update" and "bzr switch" under the single command "update". But the missing feature discussed here is closer to "bzr switch" than it is to "bzr update". Please take a look at bug 183559 discussion for details (and please tell me if I am wrong, or if I seem to be missing something).

On Mon, 2008-05-19 at 22:48 +0000, Miguel González Cuadrado wrote:
> @Michael: My point is that bug 183559 and this bug discuss the same
> missing feature, but this missing feature would be better implemented
> as part of the "switch" command than as part of the "update" command.
> The reason why "update" sounds more natural is that other revision
> systems perform the equivalent of "bzr update" and "bzr switch" under
> the single command "update". But the missing feature discussed here
> is closer to "bzr switch" than it is to "bzr update". Please take a
> look at bug 183559 discussion for details (and please tell me if I am
> wrong, or if I seem to be missing something).

I had looked at it, and it would seem to me to be similar in that this
sort of functionality is also desired with the switch command. For
example, in Subversion, you use update as a time machine within a
branch, and you use switch to move to another branch in the same
repository.

However, the major difference is that in Subversion, you use a whole
repository and store branches within it (and pseudobranches which are
tags, etc.). In bzr, you frequently use one branch in a directory,
optionally as part of a larger shared repository.

'bzr update' moves within a single branch, and 'bzr switch' moves among
different branches. This would mean that the -r useful would likely be
useful in both, with different use cases.

--
Michael B. Trausch <email address hidden>
home: 404-592-5746, 1 www.trausch.us
cell: 678-522-7934 im: <email address hidden>, jabber
Ubuntu Unofficial Backports Project: http://backports.trausch.us/

Milestone 0.13 for this is a sad joke.

I've associated a new branch, which is John's branch updated against bzr.dev.

Here are John's latest comments from the mailing list - help in addressing these issues would be appreciated!

John Arbash Meinel has voted resubmit.
Status is now: Resubmit
Comment:
A few issues:

1) We need to have whitebox testing of WT.update in workingtree_implementations. This is updating the api to allow a 'revision' parameter, and we should make sure all implementations continue to do so.

2) We need a NEWS entry describing the API break (as plugins that implement a WT will now need to accept a revision in their update
function.)

3) You are using "revision[0].in_history(branch).rev_id" which should be replaced with "revision[0].as_revision_id(branch)". The latter is a newer function that doesn't have to do as much work in most cases.

4) This code still uses a form of "lookup the -r XXXX" in the local branch, and only if it can't be found look in the master branch. I feel like it should always be resolved in the master branch. That way "bzr update -r -1" is always the same as "bzr update". This was the crux of the discussion, IIRC, and why it wasn't merged way back when.

5) This is invasive enough that I don't really want it in 1.7, but I would be happy to see a cleaned up version merged into 1.8 as soon as it opens.

I didn't do a fully thorough trawl through the code, but that should be enough to refine this patch some more.

For details, see:
http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C01aa01c90a40%24b45d2e00%241d178a00%24%40com.au%3E
Project: Bazaar

I ack all of John's issues.

I'd like to add that if we change the API we need to bump
bzrlib.api_minimum_version too.

-Rob

I am sorry I can't understand the technical discussion about the implementation of this feature, but I just realised something that may be relevant, or not at all, or it may already be in the technical discussion or in the proposed patch without me having spotted it.

I think that making "bzr update -r revno" or "bzr switch -r revno" would be equivalent to virtually making a branch with "bzr branch -r revno", and then switch'ing to the new virtual branch. Maybe the whole thing would be equivalent to bzr having a virtual branch for every revision, and then making "bzr switch -r revno-virtual_branch" ("bzr" should make sure that such virtual branches are not committable to). I have no idea whether this is feasible or not.

Bumping to High; it's the second highest bug on <https://bugs.edge.launchpad.net/bzr/+bugs?orderby=-users_affected_count>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> Bumping to High; it's the second highest bug on
> <https://bugs.edge.launchpad.net/bzr/+bugs?orderby=-users_affected_count>.
>
> ** Changed in: bzr
> Importance: Medium => High
>

I have my doubts about the accuracy of the "users_affected_count", but I
suppose now that it is visible, it will get more people actually marking
it appropriately.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkspAMEACgkQJdeBCYSNAANb/gCfZavv4fTs4RCXKX3847PSjZZk
htkAnjn1vCmDy6A+C2+/cDhWMJs2nPE7
=OIrw
-----END PGP SIGNATURE-----

This bug also has the oldest outstanding patch, so for that reason too
would be nice to revisit.

--
Martin <http://launchpad.net/~mbp/>

>1) We need to have whitebox testing of WT.update in workingtree_implementations. This is updating the api to allow a 'revision' parameter, and we should make sure all implementations continue to do so.

>2) We need a NEWS entry describing the API break (as plugins that implement a WT will now need to accept a revision in their update
function.)

>3) You are using "revision[0].in_history(branch).rev_id" which should be replaced with "revision[0].as_revision_id(branch)". The latter is a newer function that doesn't have to do as much work in most cases.

I've done these three in my attached branch, except that as_revision_id apparently can't be used in both cases, because we rely on the side effect of in_history checking it's really in the repository.

> 4) This code still uses a form of "lookup the -r XXXX" in the local branch, and only if it can't be found look in the master branch. I feel like it should always be resolved in the master branch. That way "bzr update -r -1" is always the same as "bzr update". This was the crux of the discussion, IIRC, and why it wasn't merged way back when.

I rarely use bound branches and to me it seems reasonable that it would look in the master but I don't have a strong opinion. Was there a real wish for it to be done locally or was that just easier to write? (I'll have a look in old mail.)

Updated patch for review here https://code.edge.launchpad.net/~mbp/bzr/45719-update-r/+merge/16476

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
>> 4) This code still uses a form of "lookup the -r XXXX" in the local
> branch, and only if it can't be found look in the master branch. I feel
> like it should always be resolved in the master branch. That way "bzr
> update -r -1" is always the same as "bzr update". This was the crux of
> the discussion, IIRC, and why it wasn't merged way back when.
>
> I rarely use bound branches and to me it seems reasonable that it would
> look in the master but I don't have a strong opinion. Was there a real
> wish for it to be done locally or was that just easier to write? (I'll
> have a look in old mail.)
>

I believe the idea was that connecting to the master is slow, and thus
can add 5+s to something that would otherwise complete quickly.

There is currently a disagreement among the devs as to whether we should
make heavyweight checkouts exactly like lightweight (and thus have to
connect to the master to get any information except for maybe text
content), or whether they should behave like "bound branches" where it
is clear that you have a local branch with side effects.

If we want the former, then I feel it must lookup in the master. (this
is currently why 'bzr nick' connects to the master branch, etc.)

*I* prefer bound branches, because connecting when you don't have to is
annoying. (try using a heavyweight checkout with a prompt that shows you
the current branch nick...) However, I get the impression that I'm in
the minority.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksw2GEACgkQJdeBCYSNAAO8NgCdESTmlAq8LdqYWYLKy/GkFL3h
FVAAnj02aul/xr8BX7RMQAhH704ExdX5
=d+eo
-----END PGP SIGNATURE-----

It seems to me that if you have all history locally, you are probably quite interested in avoiding network round-trips - consider how long it can take to initiate a ssh connection, for example.

Dear Developers,

I just wanted to add my 2 cents as a Bazaar user.

I've been using CVS professionally for years. Recently we switched over to bazaar (main motivation: file renames). I have generally liked the tool, and we use it in a centralized style.

However, I was very surprised that I couldn't "update" my working directory to older revisions in the way I was used to doing with CVS. I have used "cvs update -r" countless times to retrieve earlier versions of the codebase into my working directory, generally to:
* try and track down which change introduced a bug
* compare the performance of different versions on specific testcases
* inspect earlier versions of the code base, for whatever reason

In CVS, this backtracking, time-machine-like ability works well even if some files have been locally modified (those files weren't touched). Indeed, I wouldn't want to be forced to commit changes if I want to backtrack. That said, given how easy it is to uncommit in bzr, there is some wiggle room there.

I think not being able to backtrack a working tree in "cvs update -r" style is a serious and unfortunate limitation of bzr's. Had I known before we committed to using bzr and moved our codebase over, I would have selected another DRCS tool for our projects.

However, I am glad previous postings seem to imply that this issue has been resolved or is being actively fixed. Is it already available in an official release then? If this is not the case, I would strongly encourage the development team to keep this bug fix as a high priority issue.

That said, thank you for your efforts in making what I think is overall a great and easy-to-use tool.

Regards,

Julien

Hi Julien,

This bug is indeed fixed in bzr2.1. Please try out the release
candidate and let us know if you see any problems.

I would indeed like to try it out, but no luck installing bzr2.1rc2 on an ubuntu 9.1 machine. Is an ubuntu install package available?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julien wrote:
> I have used "cvs update -r" countless times to retrieve earlier versions of the codebase into my working directory, generally to:
> * try and track down which change introduced a bug
> * compare the performance of different versions on specific testcases
> * inspect earlier versions of the code base, for whatever reason

For all of those purposes, you can use revert -r.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktwORoACgkQ0F+nu1YWqI0u/QCeMOk1UptElZg3pIERaJNql8U9
hKoAnR6dgY/Bs5yNHHKCD9Di5g6exvoM
=QEqu
-----END PGP SIGNATURE-----

> For all of those purposes, you can use revert -r.

Ish, sort of. cvs|svn update -r have the advantage that you can maintain local changes in the working tree whilst rolling forwards and backward. Thus, bzr revert -r is an incomplete replacement for that workflow.

I experimented with "bzr revert" a bit to understand how it works, and this is not what I am looking for. Let me explain.

The problem is that, as far as I understand, "bzr revert" does not change the revision number of the working tree (and/or branch?), as reported by "bzr revno". Thus, to bzr, revert is equivalent to applying a bunch of manual changes to the current revision to make it identical to an old revision. Indeed, after a "bzr revert" to an earlier revision, the command "bzr status -V" reports all the changes made, which can then be committed. I would expect that executing "bzr update" at this point would do nothing since the tree is seen as up-to-date, assuming no one else committed anything (I didn't try this though). That would make sense, since bzr is still comparing the working tree to the latest revision of the branch. Now, this behaviour is fine if the idea is to actually undo some changes, as opposed to simply inspecting & toying with some previous versions. If I simply want to inspect previous versions, I wouldn't want "bzr status -V" to list all the files changed between the older revision and the current one.

The behaviour I would expect from "bzr update -r" is as follows (I haven't been able to try Martin's implementation yet). Let's assume the most recent revision committed, and also that of my working tree, is rev 100. Assume I have manually modified one file, named foo. At this point "bzr status -V" should tell me that only foo has been modified, and "bzr revno" should return "100". Now, I execute "bzr update -r 95". This should change all files in my working tree to their state as of rev 95, except for those I have manually edited, which should be left as is. Following this, if I execute "bzr status -V", only the file foo should be listed as edited or added or deleted (assuming it was under revision control in rev 95). Furthermore, the command "bzr revno" should now tell me that I am at revision 95. If I now perform "bzr update" to bring the working tree back up to the latest version (100), foo should again be left alone. While scrolling through history using "bzr update", I would not expect "bzr commit" to commit any changes except to those made to "foo", since only foo is listed as changed by "bzr status -V".

Another way to look at all this is that "bzr update -r 95" should give me a working tree in the same as "bzr checkout -r 95" (I assume "bzr revno" would tell me that the current revision is 95 after such a checkout). In contrast, "bzr revert -r 95" should give me a working tree in the same state as that produced by the command "bzr checkout (latest rev, i.e. 100)", then followed by a set of patches to make the working tree be identical to that of rev 95. These patches can then be committed (and are listed by "bzr status").

One final comment regarding the behaviour of bzr revert or update when some files have been edited. I would advocate that these files are *not* changed or renamed when doing a "bzr update". This is what happens with CVS. Thus if I have modified foo, then "bzr update -r 95" followed by "bzr update -r 100" should leave my tree *exactly* like it was before. I would absolutely ...

Thanks Max, you nailed the difference in 3 lines and I agree 100%.

Is the new behaviour of "bzr update -r" like what Max and I describe?

I definitely think the documentation should clarify some of these issues, particularly what happens with "bzr revno" and "bzr status -V" after one does a revert, versus an update.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julien wrote:
> I experimented with "bzr revert" a bit to understand how it works, and
> this is not what I am looking for. Let me explain.
>
> The problem is that, as far as I understand, "bzr revert" does not
> change the revision number of the working tree (and/or branch?), as
> reported by "bzr revno".

Sure. If it did, it would be update, not revert.

> If I simply want to inspect
> previous versions, I wouldn't want "bzr status -V" to list all the files
> changed between the older revision and the current one.

Why is that a problem?

> One final comment regarding the behaviour of bzr revert or update when
> some files have been edited. I would advocate that these files are *not*
> changed or renamed when doing a "bzr update". This is what happens with
> CVS.

No, it's not. In CVS, the differences between r100 and r95 are applied
to foo when you update, and if they conflict with your uncommitted
changes, you get conflict markers in the file.

Bazaar update largely emulates the behaviour of CVS, and it won't change
to do what you've requested.

> Thus if I have modified foo, then "bzr update -r 95" followed by
> "bzr update -r 100" should leave my tree *exactly* like it was before.

In the absence of conflicts, that will be the case with Bazaar.

> Indeed, I don't actually agree with how revert makes backups of edited
> files. This makes it impossible to undo the effects of a revert with a
> subsequent revert, if some files were edited. Edited files should be
> sacred. As far as I'm concerned, bzr should never modify or rename them
> without the user's explicit intent.

The revert command is the user's explicit intent. The backup files are
provided for situations where the user realizes their intent was wrong
afterwards.

> Finally, I would also suggest that the documentation for revert be
> updated to make it clear that the revno does not change. Should I file a
> bug for this?

If you like.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktwYx8ACgkQ0F+nu1YWqI3omQCfZ4/mUSaByJToyCbOVEOrcDbq
i4EAmwT/W0D835FMrHihCDG1LmAW5g3E
=yMhv
-----END PGP SIGNATURE-----

> > If I simply want to inspect
> > previous versions, I wouldn't want "bzr status -V" to list all the files
> > changed between the older revision and the current one.
>
> Why is that a problem?
>
If I actually want to do a revert, I can see that this makes sense.
For update however, I wouldn't want the list of files that I edited to
be overwhelmed by the list of changes between the two revisions.

> > One final comment regarding the behaviour of bzr revert or update when
> > some files have been edited. I would advocate that these files are *not*
> > changed or renamed when doing a "bzr update".  This is what happens with
> > CVS.
>
> No, it's not.  In CVS, the differences between r100 and r95 are applied
> to foo when you update, and if they conflict with your uncommitted
> changes, you get conflict markers in the file.
>
> Bazaar update largely emulates the behaviour of CVS, and it won't change
> to do what you've requested.
>
You're absolutely right. I had forgotten that CVS merges the
differences, and it makes sense that bzr do the same.

> The revert command is the user's explicit intent.  The backup files are
> provided for situations where the user realizes their intent was wrong
> afterwards.
OK. This makes sense also.

Thanks for the help.

Julien

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julien wrote:
>>> If I simply want to inspect
>>> previous versions, I wouldn't want "bzr status -V" to list all the files
>>> changed between the older revision and the current one.
>> Why is that a problem?
>>
> If I actually want to do a revert, I can see that this makes sense.
> For update however, I wouldn't want the list of files that I edited to
> be overwhelmed by the list of changes between the two revisions.

All I'm saying is that revert is an option for the use cases you listed:

* try and track down which change introduced a bug
* compare the performance of different versions on specific testcases
* inspect earlier versions of the code base, for whatever reason

It's a bit surprising to me that you would also want to retain
uncommitted changes and examine them while doing those things, but if
you do, I agree that revert is not suitable.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktwfdoACgkQ0F+nu1YWqI2iWACeKNRbcmnsOvXuCQU4nDMZ1Qtl
7y0An2qDTEu3cGTb9JZpZmdLa01TgJBJ
=H4ZY
-----END PGP SIGNATURE-----

I remember from my CVS days that this used to happen, but can't come up with a clear example now. It was probably because I version control the logfile output of some of my testcases, to have a "golden" version. If I introduced a bug, I would catch the problem when comparing the committed, golden logfile to the newly generated one. Then, I would try and roll back the source code (sometimes a subset of it) and re-run the testcase until the test output compared favourably with the golden version. Hopefully that makes sense -- it's been a while.

Even without uncommitted changes, it should be possible to get a clean checkout of some previous revision into one's working directory, and with "bzr status -V" reporting in a very satisfying way that you haven't edited anything. Otherwise I cannot distinguish my recent edits from changes due to the rollback. Therefore, I'm looking forward to trying bzr update!

By the way, will "bzr update -r" work on specific files or directories, or will the rollback necessarily be applied to the entire tree? I noticed that there is a "DIR" argument to update in the 2.1 user reference manual. If there is granularity, I guess this begs the question as to what the revno is. It would be nice to be able to roll back a specific module instead of the whole project.

I've really had no luck installing the release candidate. Is there an Ubuntu package available?

Thx

Julien

On 9 February 2010 09:40, Julien <email address hidden> wrote:
> I've really had no luck installing the release candidate.  Is there an
> Ubuntu package available?

Apparently not yet, but there should be one soon.

If you're having trouble installing from source you can open a
question about it.

--
Martin <http://launchpad.net/~mbp/>

This was released in 2.1.0, so no reason for it to stay open on that train.