[mythtv] Weird File Mod Times in SVN 13887

[R. G. Newbury]

Roo wrote:
> On 15/07/07, R. G. Newbury <newbury at mandamus.org> wrote:
>> I pulled down SVN 13887 yesterday at work, burned the mythtv, myththemes
>> and mythplugins folders to a CDRW using K3B, copied that to the mythbox
>> t home and started to compile it last night.
>> Compiling mythplugins failed with a reported error something like 'Clock
>> skew error ...the file time is 5.6e5 s in the future...
> 
> IIRC, make uses the modified time to determine is the file is modified
> (compared against a cache of mod times), the clock skew warning is
> letting you know it has found files with a timestamp in the future. If
> the timestamps aren't right then make may not do the right thing.
> 
> You could recursively "touch" every file in the source tree then
> recompile, I think make would be OK with that, every file has been
> modified with a mod time now in the past. Maybe "make --touch" might
> help, otherwise a find | xargs touch or similar.
> 
> Another option might be to run "make -B", unconditionally make all
> targets, skips the modification detection,  probably will work.

I understood why 'make' threw the error. What I didn't/don't understand 
is *how* this error could arise.

Yes, I used touch to fix a few files. Then I realized that the 'bad' 
files were in a plugin module I did not want anyway, but which I had not 
explicitly disabled. So I just amended my configure-caller script to 
disable the module.

Thanks for the discussion. This still does not explain exactly what 
happened. I know that the date/time are correct on my desktop at work. 
It runs ntp on a cron and I referred to the time, on the panel a few 
times on Friday afternoon...I *suppose* it could have gotten out by a 
week...But then SVN's date scheme would properly show (from my end) that 
all of the files were more than a week old and the compile would show no 
error. The mythbox runs ntpd, of course, so its time is correct anyway.

In fact, the file dates were in futuro to real time.
Your comment "the svn repo has ended up with an incorrect time for the
 > "last commit". Either due to svn repo server  misconfiguration or a
 > svn client side discontinuity in its date/time." appears to be correct.

I have never touched the subversion config on any of my computers, so I 
suspect that -use-commit-times' is not enabled on the desktop. I infer 
that using that would give me varied time-stamps (equivalent to using 
'cp -a' on the files). And NOT using it, should mean that the files *at 
my end* should be time-stamped at the time of creation. And the majority 
of the files carry the correct July 13th timestamp. Only *some* are 
dated a week in advance....Which makes no sense either way....Curiouser 
and curiouser....

Will have to check the computer at work, carefully....

<discussion redacted>


-- 
              R. Geoffrey Newbury			


        Helping with the HTTP issue
<a href="http://www.w3.org/Protocols/">HTTP</a>