Req: Reset mtimes on reverts.

[Blake Winton]

Aaron Bentley wrote:
> Blake Winton wrote:
>> I'ld like to use bzr for my weblog, and it uses the mtime of files
> The Make build tool (and others like it) use the mtime to determine
> whether a file has been modified since it was last built.
> 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.

If you revert back to an "older" version, and don't clean your output, I 
wouldn't be surprised at your getting strange results.  :)

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

That sounds fair.  I'ld be more than happy to have it as an option, or a 
patch that's only applied to my tree.

Although I still believe that "Version Control Systems" are useful for 
much more than software development.  Heck, I worked at a company 
(PCDocs) whose very expensive product was basically a half-baked 
implementation of CVS for lawyers and secretaries.  And Greg Wilson has 
developed a course which teaches non-developers the useful parts of 
software development, like version control.

For that matter, I also believe that Make is on its way out.  It's been 
ages since I've had to use a makefile.  A setup.py, or a build.xml, seem 
to be what I use these days.

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

That wouldn't be so useful for my purposes, unless I wanted all my files 
to appear on the day I last committed.  :)

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

Yeah...  That makes sense.

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

So, what would working_tree.get_file_mtime give me?

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

Thanks!

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

It's true, and I have hosed myself on that very fragility, but doing it 
the way they do avoids the need to open and read every file.  It also 
fits in quite nicely with the PyBlosxom philosophy of your weblog just 
being a bunch of text files in a directory tree.

There is of course a plugin which opens and reads every file to get the 
time, but I don't use it because it seems too heavyweight.  (Although, 
thinking about it, it would be fairly simple for me to write a program 
which stores the mtimes in a file, and I could check that file in to bzr 
when I added a new entry, since the date of that file wouldn't matter, 
just its contents.)

And hey, weren't you just using Make's similar modification-time 
behaviour in support of one of your previous points?

Later,
Blake.