----- Original Message ----
> From: David Weintraub <qazwart_at_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
Received on 2010-10-27 06:23:51 CEST