"Noel L Yap" <[EMAIL PROTECTED]> writes:
> [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.
The file is generated all the time I call the application. If I chmod
it so that it can't be modified, the tool doesn't work.
> >> 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.
I don't like any since both are workarounds. I can implement the first
easily, though.
> >> 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.
:-)
Yes, we have. but we aren't the project leaders and we can only
suggest things to be implemented. But nothing prevents us from using
some patches...
> >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.
Make isn't a perl script... Actually, a dozen of 2000-3000 perl
scripts... This is really messed!!! (And I thought I had messed
programs...)
--
Godoy. <[EMAIL PROTECTED]>
Departamento de Publica��es
Publishing Department Conectiva S.A.
