Req: Reset mtimes on reverts.
aaron.bentley at utoronto.ca
Wed Jul 25 21:56:26 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
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
-----END PGP SIGNATURE-----
More information about the bazaar