Make cvs ignore some changes in files
Hi there, I have a small question for you all I have some genereated source-files that I need to have in the cvs (** Yes i know that some of you here do not like that generated stuff gets put into the cvs-system, but due to the fact that some persons with access to this project is not allowed to use (or cannot execute) the generator the generated source files need to be in the cvs, this is how we do it, and how we will do it in the future, so do not flame me for this **) the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. What I wonder now, is is there anything i can do to this row so that cvs does not see that the file has been changed, is there any cvs-tag for this? Since I do not wich to have xxx revisions of the same file where 90% of them is just this change in remark.. Christian Andersson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
From: Christian Andersson [mailto:[EMAIL PROTECTED]] I have some genereated source-files that I need to have in the cvs Why must they be in CVS? the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. Again, why does something generated by a build need to be revision controlled? -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
-Original Message- From: Christian Andersson [mailto:[EMAIL PROTECTED]] Does it really matter why? WHY is NOT the problem... how to make CVS work in my case is the important thing to solve... No, how to get the generated file to the developers is the problem to solve. CVS is just one potential means to that end. And as I said, some users are not allowed to use the generator, OR they cannot use the generator, therefore they will not be able to get the source of the generated files and therefore cannot compile the project... In this case, CVS is being used as a file transfer tool, not a revision control system. Are there other means available other than CVS that you may use? For example, something in a build script could copy the generated file to a common area which the restricted developers could have a symlink to (assuming a UNIX system). Riechers, Matthew W wrote: From: Christian Andersson [mailto:[EMAIL PROTECTED]] I have some genereated source-files that I need to have in the cvs Why must they be in CVS? the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. Again, why does something generated by a build need to be revision controlled? -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
From: Christian Andersson [mailto:[EMAIL PROTECTED]] the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. From: Riechers, Matthew W Again, why does something generated by a build need to be revision controlled? The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. I have a similar need where a tool from a real-time OS vendor generates a makefile that has embedded path information. Compiling and linking don't require the tool if the makefile is available, but the path information has to be adjusted if the base directory is different. The vendor tool (a project builder GUI) does not work well in an automated build script. Therefore, the automated build scripts that I use for creating a release requires the generated makefile, but appropriately modified. My solution was to write a simple program (sed did the job well) that changed the generated makefile into a canonical form. I store the canonical form in the repository under a different name: Makefile.cache. The build procedure manages the local makefile. - If the local makefile does not exist, then the build procedure creates it from Makefile.cache and updates the date of the local copy of Makefile.cache (with touch). - If the local makefile has changed (test that it is newer than Makefile.cache), then the procedure creates the canonical form and compares it to Makefile.cache (with cmp). --- If the two files are the same then the date of the local copy of Makefile.cache is updated (with touch). --- If these are different, then Makefile.cache is replaced with the new version. The next cvs commit will commit the new Makefile.cache along with any new or changed source files. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
From: Riechers, Matthew W Again, why does something generated by a build need to be revision controlled? I wrote: The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. but then I wrote: --- If these are different, then Makefile.cache is replaced with the new version. The next cvs commit will commit the new Makefile.cache along with any new or changed source files. I just realized that this explains why, in this case, the files *must* be revision controlled. The new version of Makefile.cache corresponds to the new versions of the other files in the directory. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
--- Frederic Brehm [EMAIL PROTECTED] wrote: The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. Have you tried: 1. Version control the generated file. 2. Build the generated file if the necessary tools are available. 3. Copy the generated file to a place where the rest of the build will use them. IMHO, the problem is that you're trying to use a version control tool as an installation tool. Doing the above should avoid this. HTH, Noel __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
--- Frederic Brehm [EMAIL PROTECTED] wrote: I wrote: The generated files don't need to be revision controlled, but they need to be available to people or tools who cannot run the tool that generates the files. The most convenient way to make the files available is to put them into the repository alongside the other files that are also needed. The side effect of this is that the files become revision controlled. but then I wrote: --- If these are different, then Makefile.cache is replaced with the new version. The next cvs commit will commit the new Makefile.cache along with any new or changed source files. I just realized that this explains why, in this case, the files *must* be revision controlled. The new version of Makefile.cache corresponds to the new versions of the other files in the directory. I don't understand, if Makefile.cache has to be in synch with the other files: 1. Why are there systems that are able to commit, but can't build Makefile.cache? 2. Why would you not want to commit Makefile.cache once it's regenerated? 3. Why can't the build system just generate Makefile.cache without it being versioned? Noel __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
At 07:06 AM 8/22/2002 -0700, Noel Yap wrote: Have you tried: 1. Version control the generated file. Yes, I version control a canonical form of the generated file. 2. Build the generated file if the necessary tools are available. The tool does this without asking when it is run. It's a GUI, though, so it doesn't run in an automated (no manual intervention) build. 3. Copy the generated file to a place where the rest of the build will use them. A simple copy won't work. The file has to be version controlled with the other files in the directory. See my previous message. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Make cvs ignore some changes in files
At 07:12 AM 8/22/2002 -0700, Noel Yap wrote: I don't understand, if Makefile.cache has to be in synch with the other files: 1. Why are there systems that are able to commit, but can't build Makefile.cache? There are no such systems. I'm not sure where my text misled you into thinking that, but that's not what I meant to say. 2. Why would you not want to commit Makefile.cache once it's regenerated? You cannot commit it until the other corresponding source files are committed. If you commit new or modified source files, then you must commit the modified Makefile.cache. Yes, there have been a couple of times where everything wasn't properly committed and it broke the build for other developers. That's no worse than other typical errors like forgetting to cvs add a new file and committing other modified files that depend on the new file. 3. Why can't the build system just generate Makefile.cache without it being versioned? Building Makefile.cache from scratch requires running a GUI tool. The GUI cannot be run without manual intervention. The build system is used for automated (read no manual intervention) builds to create a release. It's the middle part of cvs export; build; package. Just for the record, I dislike this GUI tool and the extra conditions it puts on the build and the extra work I had to do to get the builds to be repeatable. This method was the best solution I could find. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Make cvs ignore some changes in files
Christian Andersson writes: the problem I have is that these files often gets generated when there is nothing changed to them (it is part of some compilation sections) what happens is that I get new generated files that has only one difference, a remark in the file telling when it was generated.. What I wonder now, is is there anything i can do to this row so that cvs does not see that the file has been changed, is there any cvs-tag for this? There's nothing in CVS. I'd suggest either changing the generator to not insert that remark or postprocessing the file to remove it. -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Make cvs ignore some changes in files
Does it really matter why? WHY is NOT the problem... how to make CVS work in my case is the important thing to solve... No, how to get the generated file to the developers is the problem to solve. CVS is just one potential means to that end. why I cannot change the distribution is beyound me since it concernes politics/security, I'm not allowed to open up a different type of connection to the cvs computer for the users, cvs is the only way they can get the source file (no ftp, no ssh, no samba, etc) The users can still edit some other files in the project so it is not only a transfer problem... I asked for a sollution to MY problem, not to a different problem with how things are set up, so why not ignore why, and how and just answer my problem? Is it possible for cvs to ignore certain rows in a file when comparing for differences so that I do not have to commit the local file everytime an specific row (date-comment) in the file is changed, or fetch out the last file from the repository... /Christian Andersson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Make cvs ignore some changes in files
At 04:52 PM 8/22/2002 +0200, Christian Andersson wrote: I asked for a sollution to MY problem, not to a different problem with how things are set up, so why not ignore why, and how and just answer my problem? OK. Is it possible for cvs to ignore certain rows in a file when comparing for differences so that I do not have to commit the local file everytime an specific row (date-comment) in the file is changed, or fetch out the last file from the repository... No, CVS cannot do that. One way to solve your problem is to use your build system to process the file into another file with some canonical form and store the processed file in the repository. See the way I dealt with the makefile and Makefile.cache for my situation. Use that as a model for your situation. Fred _ Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] http://www.sarnoff.com/digital_video_informatics/vision_technology/index.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
