Req: Reset mtimes on reverts.

[Aaron Bentley]

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

Blake Winton wrote:
> And now the request:
> I'ld like to use bzr for my weblog (because I make some stupid changes
> sometimes and want to back them out), but I use PyBlosxom as my weblog
> software, and it uses the mtime of files to determine when the entries
> were written.

The Make build tool (and others like it) use the mtime to determine
whether a file has been modified since it was last built.  If revert
were to set the mtime to an old time at the same time as modifying
files, then it would confuse Make.

The file would be changed, but Make would see that the mtime was older
than the output file, and conclude that nothing needed to be rebuilt.
This would be extremely bad behavior.

Since Make is more important for software development than PyBloxom, I
think it is unlikely that we will ever support reverting mtimes as
default behavior.

> So, I'ld like it if, when I reverted ..., the mtime of the files was reset to what
> they were before I started messing with them.

Bazaar doesn't store that data.  The only data it knows is the commit time.

> I found my way ... to transform._alter_files, but
> that's kind of where I get stuck.  Is the algorithm of that method
> explained anywhere?

No, but I'm happy to answer questions.

> Should I always re-set the mtime, or only if the
> content changed?

Only if the content changed, I expect.

>  I think I can just call
> working_tree.get_file_mtime(file_id) to get the mtime of the checked in
> file, but I'm not sure if that would work for historical revisions. Does
> the mtime of checked in files get stored?

No.  Only the commit time is stored.  But RevisionTree.get_mtime will
provide the commit time.

> (Also, a pointer to where I should add a test case for this would be
> much appreciated.)

It would make sense to put it in test_transform.py

Aaron

P.S. PyBloxom's modification-time behavior sounds really fragile.  It
would make a lot of sense to store modification time as part of the file
format, since the last file modification isn't necessarily the same as
the last content update.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp7j60F+nu1YWqI0RAt2YAKCCDwugTLufb+Y0bfvVupG0x7DRIACbBLeU
JZZ5RMOA8kDm6pwLTFDxbIM=
=FBQL
-----END PGP SIGNATURE-----