Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Thanks all, I really appreciate the feedback and comments on this. I think I will go with the methods each of you have described by using an internal revision number. Cheers, Trevor "Bo Berglund" <bo.berglund at telia.com> wrote in message news:op5i81pfv1090o75nkpq37hkeg0gvr22l6 at 4ax.com... > On Mon, 16 May 2005 14:47:47 -0700, Glen Starrett <grstarrett at cox.net> > wrote: > >>> You would probably be better handling it on the client - have a program >>> that runs after update/checkout and modifies all the binaries with their >>> current version number, based on CVS/Entries. >> >>Better yet -- A script that runs just before commit that increments an >>internal revision number (not necessarily matching the CVS revision). >>Extract that info after the commit with the CVS version number (and >>maybe a MD5 sum too for good order) and store it and you have a >>cross-reference that you can use to look it up later. >> >>That assumes that Oracle Forms developer supports some sort of API where >>you can automate the incrementing of those numbers. >> > > He said in the beginning that he has written a program that can > manipulate the contents of the files in the "right" way, so there is > probably no need for a regular Oracle API. > I think that the suggestion you have put forward is doable, it would > probably work something like this: > > 1. In commitinfo > Here the aforementioned program goes into action by locating the > previous value of the "magic" number in the file submitted. This can > be done inside the temp dir. The program then increments this number > in some way (simple inc or getting a new value from some kind of > databbase). Saves it back into the file in temp. (This measn that the > file committed by the user actually is changed before it reaches the > CVS repository.) > Then exit with 0 result so CVSNT can continue. > > 2. In postcommit or loginfo > Now grab the file again with the special program and read the magic > number *and* the CVS revision, which at this point is available. > Store the combination away into a searchable database or textfile. You > may even have this text file in the CVS module if you run postcommit > because the postcommit can edit the file and then commit it to CVS. > > With this scheme there will be a searchable database or file where the > magic identifier in the Oracle files can be matched to CVS revisions > for retrieval if need be. > > > > /Bo > (Bo Berglund, developer in Sweden)