jam> Vincent, could you explain why this is 'udd'?
Because it was mentioned at UDS as the most annoying bug in bzr
when it comes to use bzr for packages.
jam> I think it would be okay for TreeTransform to set the
jam> mtime of all of the files it creates to a fixed time.
Yes, that's the point. Which time doesn't really matter as long
as it's the same for all files.
The bug is clearly about a generated file getting an earlier date
than its corresponding source file because then it appears to
build tools as it needs to be rebuilt.
jam> I would be a little bit concerned about overhead, but 1
jam> sys-call to set the time for the file we just created
jam> doesn't seem too bad.
That's the idea, since the file is already opened, it shouldn't
add any IO overhead only a syscall which should already have
whatever data is needed in memory.
jam> What would be bad is if we can't set the time backwards.
That's not what was asked for.
jam> Meaning, I would set the time for all files to the
jam> creation time of the *first* file.
Yes.
jam> Then you can do it on-the-fly. If you have to do it for
jam> the time of the *last* file, then you have to go back
jam> and touch all the files you just created after-the-fact,
jam> which isn't nice.
>>>>> "jam" == John A Meinel writes:
jam> Vincent, could you explain why this is 'udd'?
Because it was mentioned at UDS as the most annoying bug in bzr
when it comes to use bzr for packages.
jam> I think it would be okay for TreeTransform to set the
jam> mtime of all of the files it creates to a fixed time.
Yes, that's the point. Which time doesn't really matter as long
as it's the same for all files.
The bug is clearly about a generated file getting an earlier date
than its corresponding source file because then it appears to
build tools as it needs to be rebuilt.
jam> I would be a little bit concerned about overhead, but 1
jam> sys-call to set the time for the file we just created
jam> doesn't seem too bad.
That's the idea, since the file is already opened, it shouldn't
add any IO overhead only a syscall which should already have
whatever data is needed in memory.
jam> What would be bad is if we can't set the time backwards.
That's not what was asked for.
jam> Meaning, I would set the time for all files to the
jam> creation time of the *first* file.
Yes.
jam> Then you can do it on-the-fly. If you have to do it for
jam> the time of the *last* file, then you have to go back
jam> and touch all the files you just created after-the-fact,
jam> which isn't nice.
Agreed.