----- Original Message ---- > From: David Weintraub <qazw...@gmail.com> > I'm not sure what you are planning on doing, but usually the RCS > Keywords are not a good idea. They usually cause more problems than > they solve. What usually works better (especially in C and C++) is to > define macros at compile time that are embedded in your program as > strings. For example, you could have an "About Box" that will display > this information or if your run your program with a --version switch.
I am already using some macros, etc. However, I find that using things that rely on the programmer to make a modification can be troublesome and it is far to easy to forget to change the version and build date information. Versus using the RCS keywords to record some of the same information. > This will give you more flexible control -- for example, you can use a > release number that corresponds to your tags. And, you don't have to > worry about forcing programming changes just to munge the $Date$ > keyword. I don't want to munge it. I just want to print it. I'm not even particular about the format.Which is why a URL last commit date RCS Keyword would work just fine. I've also seen some others in the past - such as autoincrementing a macro; however, that is even more broken as it requires it to be checked back in, so then two programmers could generate the same numbers separately. Ultimately there is no real good solution, only a series of solutions that are good enough and RCS keywords is one approach. It may not be for everyone, but it does have its purposes. > However, if you must use RCS keywords, you can modify a property that > will force a diff in the file without modifying the file itself. Again that would require the programmer to do something. Versus what I proposed, which would just work since as the name space gets copied from one URL (e.g. trunk) to another (e.g. tags) the property would automatically change. Additionally, svnversion doesn't work b/c it only works on the local working copy, which doesn't work when you've exported the code. (since it just reports that was exported). I've already gotten around the revision thing somewhat by requiring the programmer to include it in the release tag, and then having some custom code that can parse the HeadURL to get the information - but only b/c it knows how to decode it out of the tag name and it knows a little bit about our SVN repository structure. Ben
