SvnRev SvnRev is a little program that writes the current revision number of project into a C/C++ header file, a Java package file or a C# class file. This revision number is stored in constants (macros in t
Download

SvnRev Ranking & Summary

SvnRev Tags

Stamp CVS CVS Resource Subversion integration VB6 Subversion subversion Subversion Client subversion configuration Subversion logs spectrum to cvs subversion monitor Subversion Library manage Subversion server Subversion administration CVS client cvs control cvs modules work cvs cvs function Subversion server CVS options Subversion interface SubVersion editor access CVS subversion management Python Subversion CVS file stamp application stamp component C++ header RCS Subversion deployer subversion to mercurial CVS successor cvs import

SvnRev Description

Stamp your applications or components with revision numbers SvnRev is a little program that writes the current revision number of project into a C/C++ header file, a Java package file or a C# class file. This revision number is stored in constants (macros in the case of C/C++), both as a number and as a string. It gets the revision number from the "RCS keywords" that must be present in the source files. SvnRev is specifically designed for the Subversion version control system, but it can also be used with CVS and RCS. SvnRev is a self-contained utility that does not rely on a particular IDE. SvnRev is a portable utility and should run on every environment on which a conforming C compiler is available. Our aim was to use it from a "makefile" and to attach to a version control system, and specifically to the Subversion system. Why use SvnRev? Computer programs have versions. Each component (DLL, ActiveX object, OLE server, embedded firmware, etc.) may have its own version. If the world were perfect, there should not exist two different components with the same version number. In practice, "stealth" upgrades happen, especially during the beta period. There are numerous different releases of MSVCRT20.DLL that all have the same version number 2.11.000. In a similar way, incompatible releases of CTL3D.DLL version 1.0 and COMDLG32.DLL version 4.00 are "out there". What is needed to distinguish the various components from each other is to attach a "revision number" to the version string of the component. When such a scheme is set up (and the revision number is part of the version number), developers no longer accidentally release an updated component with exactly the same version stamp as the previous release. When the version number is present in the "About" box and/or in the version resource, the user can quickly verify exactly what version he or she has, and when this is communicated to the developers, bugs might be quite a bit easier to reproduce. In more popular terms: if you have ever asked a customer or a colleague "of what date is that component?", you should consider using SvnRev. File date/time stamps have a (well deserved) reputation of being unreliable. There are several utilities to maintain an automatically increasing build number for every compile. However, this has the disadvantage that there is no direct link between the build stamp and the version control. To get such a link, you would need to check in the file that holds the current build number into version control. In multi-developer groups, this machine-generated, frequently changing file, will become a nuisance for the version control system. Actually, you do typically not put machine-generated files in version control. SvnRev uses a different approach: it queries the build number from the keywords that a version control system maintains in a source file. More specifically, SvnRev uses the "$Id:$" keyword (and optionally two others). Subversion has the convenient property that it uses only a single revision number for an entire project, instead of a separate revision number per file. This is not the case with CVS and RCS; see the section "Using SvnRev with CVS & RCS" for details on using SvnRev with CVS/RCS. SvnRev does assume that you commit your changes to version control before you send a product/update to someone. If SvnRev detects a difference, it adds a "modified flag" to two of the macros/constants that it generates. The reasoning behind this is that if your local copy of the source code contains changes that are not yet in version control, the revision number of the application/component that you sent is linked to the wrong revision number in Subversion. The number is still likely to be different from any earlier application/component that went out of the door (unless you use version control badly, or send out updates far too quickly), but finding the correct revision back may be hard or even impossible. Therefore: commit your changes first, then build the final release that you will deploy.

SvnRev Related Software