Bazaar

Bug #45719
Comment #38

Comment 38 for bug 45719

Revision history for this message

Aaron Bentley (abentley) wrote on 2010-02-08: Re: [Bug 45719] Re: update command cannot take a revision number

#38

-----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-----

-----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?

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-----