[EMAIL PROTECTED] on 05/22/2000 05:16:36 PM
>> I see a few things you can do (none are elegant):
>> 1. Don't regenerate the file. If nothing that the file depends on has
changed,
>> why regenerate it?
>
>It's the tool behaviour. I can't prevent that. Not now. In the future
>it will be different.
I don't understand. You *must* do something (eg call the application) -- just
don't do that something. Or, is it that, the second the application comes up,
the file is regenerated, and, for some reason, you must call the application.
>> 2. Strip out the timestamp (possibly replacing it with something generic)
before
>> doing commits. This may break the application when it goes to read
>> the file.
>
>This is what we do... But it's not a good solution to edit a file,
>remove this meta info and commit... There are always people forgetting
>to do so and there are always people yelling for these merge
>conflicts... :-(
I see two things that can be done to help with this problem:
1. Wrap CVS and have team members call the wrapper. Among possibly other
things, the wrapper will strip out the timestamps.
2. Use commitinfo to check to see if the timestamps are still there. If so,
abort the commit. I like this solution better since it's less intrusive.
>> 3. Complain to the vendor. Vendors should know better than to put variable
>> meta-information (like timestamps) inside files with real content. What are
the
>> timestamps used for? Can't the application use the file's mod time? Can the
>> application place this info somewhere else?
>
>We're changing this (it's a tool that we're developing with O'Reilly)
>but it's not the way it's working now and we need this tool to be used
>to produce new books.
It sounds like you're somewhat better off than I had thought. At least you seem
to have _some_ level of control as to the behaviour of the tool.
>Talking about the mod time, I don't know how it works on NT/95/98/2000
>and macintosh OSes. I know it would work on Unix/Linux machines...
I don't know either, but I don't think it'd be much different than how 'make'
uses it.
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
