Re: Generated files.
On Tue, 12 Sep 2000, Oliver Fischer wrote: I tent to ignore them. Since they can produced automatically, I regard them as temporary files. And this is the crux, that you can produce them automatically. Alas, this is a bit of a problem. In that there are hundreds of the @##$! things. And as I have found out, people tend to get a bit lax about booking files in. (I found out the hard way, by moving from RCS to CVS and finding nothing worked. People had been too lazy / forgot to book things in to RCS.) So what I was hoping to get to was a state where every "?" flagged file was a direct insult to the eye. A highly visible mark that here was a file that should have been "cvs add"ed but wasn't. If there are hundreds of generated files like executables lying around, then one loses the impact. Is there any mechanism to extend cvsignore to match questionable files and then use something like the "file" command to peek inside them to decide whether to ignore them or not? John Carter Work Email : [EMAIL PROTECTED] Private email : [EMAIL PROTECTED] Yell Phone : 083-543-6915 Phone : 27-12-348-4246 Carter's Compass... I know I'm on the right track when by deleting code I'm adding functionality.
Re: Generated files.
Is there any mechanism to extend cvsignore to match questionable files and then use something like the "file" command to peek inside them to decide whether to ignore them or not? This seems doable. A quick hack would be to change ign_name to take a new parameter: int am_server Change change if (!ign_name (arg)) in server.c to be if (!ign_name (arg, 1)) and change the other calls to ", 0" Then change ign_name() to look at the first character of the pattern, see if it's a "|" ... The problem is that ign_add splits on spaces. So perhaps the |xxx syntax could be used to indicate a named test (like commitinfo) in a new CVSROOT file?
Re: Generated files
John Carter wrote: Alas, this is a bit of a problem. In that there are hundreds of the @##$! things. And as I have found out, people tend to get a bit lax about booking files in. (I found out the hard way, by moving from RCS to CVS and finding nothing worked. People had been too lazy / forgot to book things in to RCS.) (Perhaps this is altogether too obvious) The way out of this is to institute a process such that things will noticeably break if people fail to check things in. Have the build process (preferably automatically and periodically) do a fresh checkout or export and build from there. You _must_ do this anyway if you are to have any confidence that your CM process isn't hopelessly broken. You can't assume that it's working, you must test it regularly.
