08 Oct, 2008, quixadhal wrote in the 1st comment:
Votes: 0
I'm trying to remember how to actually USE svn, and I remembered a feature I liked from cvs. In cvs, you could put a token in your code (comments) called $Log$, and when you did a checkout, it would expand that token to be the full log of comments from the original revision down to the current.
/*
* $Log: commands.c,v $
* Revision 1.1 2000-12-26 10:11:57 quixadhal
* Ressurection from 4.10.2z… way back from WMU.
*
* Revision 2.1 1991/09/20 16:54:46 cclub
* *** empty log message ***
*
* Revision 1.4 1991/08/09 03:50:20 quixadhal
* Added relative coordinates to several move commands.
*
* Revision 1.3 1991/08/06 00:33:02 quixadhal
* Added RCS header information for logging.
*
*/


Does svn have anything like this? Google isn't being very helpful today, and I know some of you use svn on a semi-regular basis.
08 Oct, 2008, Vassi wrote in the 2nd comment:
Votes: 0
http://svnbook.red-bean.com/en/1.5/svn.a...

This might be helpful, or thereabouts. Doesn't look like they have specific commit logs though, but I'll keep digging.
08 Oct, 2008, David Haley wrote in the 3rd comment:
Votes: 0
Wouldn't commit logs get really long after a while if they're all embedded in the file? Isn't it really easy to get the logs anyhow? I have a vim plugin that lets me do it inside the editor… I guess what I'm really asking is: what's the rationale for having the logs in the file?

At work we use CVS's $Source$ and $Header$, but not $Log$. Some of our files have hundreds upon hundreds of commits, so it would get unbearable pretty quickly. :wink:
08 Oct, 2008, quixadhal wrote in the 4th comment:
Votes: 0
Ahhhh, keyword! That's the one I didn't try… thanks Vassi!

Yes, they do indeed get pretty long. We used Header at work. It's handy to have at least that much visible in the source, because if people out there beyond the developer's circle get copies, they can look and see what revision they're actually using. With cvs keeping version numbers per file, that's vital. With svn, it's not as critical, but it's still handy I think.
08 Oct, 2008, MacGregor wrote in the 5th comment:
Votes: 0
As near as I can figure svn does not support a $Log$ keyword. If it did I would be against using it in the RaM project, pretty much because of what David says. My merc.h has been revised 440 times (actually more, that's just counting cvs commits). I really really really wouldn't want all that included in the file itself, particularly since I can get it any time I need it with a simple 'cvs log merc.h'. If you want to store the version number in the file (which I agree with), $Revision$ does that nicely.
08 Oct, 2008, Caius wrote in the 6th comment:
Votes: 0
Not exactly the same, but I have this in my makefile:
Quote
MUD_REVISION = -DMUD_REVISION=\"`svnversion -n`\"

And then I pass $(MUD_REVISION) to the compiler, and I can get the info for instance in the in-game 'version' command.
08 Oct, 2008, quixadhal wrote in the 7th comment:
Votes: 0
Actually, the one-line $Id$ tag does the job nicely for documenting the code. I think the only reason we put Log in was that, back then, we moved from RCS, to another RCS, and then to CVS, and were tired of losing the comments because there wasn't an easy way to
import/export at the time.

I was actually going to poke at that Caius….. having the overall revision visible in game isn't a bad thing. I had a more elaborate one in my mud, which build a version.h file, but the idea's the same. Nothing fancy, just a do_version that splats it at the user with a little formatting and a few statistics (memory use, etc).
0.0/7