Hi! Ralph Glasstetter wrote:
>>I know that feature from RCS/CVS. There you can define a set of static C >>strings: >> >> static const char rcsid[] = "$Id$"; > > That wouldn't help since with subversion every source file get's a different > revision number... In C++, you could define a class with an initializer that calculates the maximum at runtime, and instantiate it in every source file ;-) >>and retrieve them later (from both source and binaries) with a command >>called "ident". Similarly in SCCS, except that the command is called >>"what" there. > > ...ok, you could also parse the source files for that string during the build > process to get the largest one,... for svnrev it does not matter where the > string is located (but it works only with ASCII). > > The real problem is that the mechanism should be portable... and subversion > does not have a "GlobalRevison" key... I noticed that, too. >>>For instance in dvbcut.cpp we could then use SVN_REV in your new >>>setCaption call to identify the binary. >> >>That would require that svnrev is available when you build the binary. > > Of course,... the small tool svnrev.c should be distributed with subversion, > build prior to dvbcut and run before building that to create a svnref.h (by > reading the expanded IDs and estimating the largest). You could also run `svnversion' from the toplevel directory, at least with subversion 1.4. The real problem is, however, that not everybody has subversion installed and/or wants to build dvbcut from svn. > But probabely this could also be achived by executing a bash script > with a combination of 'grep | tr | cut' in a loop... which is also acceptable > as long as the windows version is build with mingw... ;-) It hasn't been ported to another environment yet, so... :-) >>Keywords are substituted when a revision is checked out or updated (or, >>in my case, checked in). That is, you can not check in the result from >>svnrev at the same time because you must run the program afterwards. And >>I don't want to run "svn ci" twice. Not because I'm lazy but because the >>revision will change again when you do so - therefore, the stored >>results from svnrev would always be slightly out of date. > > No,... It's not meant that you should run svnrev as the repository maintainer > and check in svnrev.h regularly (maybe only once as template with variables > set to 0). It don't has to (or should) be unter version contol... See above. Not everybody uses svn. >>I've always been using keywords with my own (CVS based) projects, and >>found them very convenient. > > It's little bit different there, since (from what I've read) all files get > the > same revision/version, right? No, file revisions are numbered individually in CVS. E.g. dvbcut.h might have revision 1.3 while dvbcut.cpp has 1.7 (simply because it was changed more often). In addition to that, you can define tags, which are symbolic names for what we know as revisions from svn - except that tags don't translate to a global revision number, but to an individual one for every file. If a file didn't change between revision A and B, both tags will point to the same version. Michael. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
