On Wed, Feb 17, 2016 at 1:56 PM, Zoltán Kócsi <zol...@bendor.com.au> wrote:
> > > 2. Does fossil store the mtime for the files?
> >
> > It doesn't, actually. It _calculates_ the mtime based on the time of
> > the commit containing it. Thus the mtime for all files aligns to time
> > of the commit which last included that file.
>
> In fact, what I saw was that fossil didn't even do that. I checked out
>
Yes, it does - i know that because i ported those bits to libfossil and was
very surprised by that behaviour ;).
> two branches (with different last mod dates) into two separate
> directories and every file had the same mtime: the current time when I
> checked them out.
Fossil NEVER sets the timestamp of checked-out/update'd files to a previous
time because this completely breaks build tools which use timestamps to
determine if a build is up to date.
> That is, fossil simply wrote the files from the
> database to the filesys and left the mtime as it was set by the system.
>
Try generating a zip file:
fossil zip trunk filename.zip
And look at the timestamps - those are the synthesized (checkin) times.
[stephan@host:~/cvs/fossil/cwal]$ f zip trunk foo.zip
[stephan@host:~/cvs/fossil/cwal]$ unzip -l foo.zip | head
Archive: foo.zip
Length Date Time Name
--------- ---------- ----- ----
0 02-14-2016 18:18 cwal_2016-02-14_171808_ed54ffc51a/
0 02-14-2016 18:18 cwal_2016-02-14_171808_ed54ffc51a/JSON_parser/
37189 02-14-2016 18:18
cwal_2016-02-14_171808_ed54ffc51a/JSON_parser/JSON_parser.c
6699 02-14-2016 18:18
cwal_2016-02-14_171808_ed54ffc51a/JSON_parser/JSON_parser.h
3703 02-14-2016 18:18
cwal_2016-02-14_171808_ed54ffc51a/JSON_parser/main.c
3539 02-14-2016 18:18 cwal_2016-02-14_171808_ed54ffc51a/Makefile
12456 02-14-2016 18:18 cwal_2016-02-14_171808_ed54ffc51a/common.make
[stephan@host:~/cvs/fossil/cwal]$ f-timeline -n 1
checkin [ed54ffc51a37] @ 2016-02-14 18:18:08 by [stephan] branch [trunk]
*CURRENT*
more experimenting/commenting on the derived overloads. It seems that the
different required return semantics of + vs += are going to make that a
non-starter.
Notice that the checkin time precisely matches the file timestamps.
A pity, really, but probably solvable. Maybe I will need to write a
> wrapper around commit that automatically generates an extra file
> containing the mtimes of all the files, then commit that file as
> well then an other wrapper around the check-out that then reads that
> file and sets the mtimes accordingly. Starts to get really hairy...
>
Indeed, but that's the state of things. When i first saw this behaviour i
was shocked by it, but the more i thought about it, the more it kind of
made sense. For a given definition of sense, anyway.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
