Embed Svn revision number in code

[mds]

Hi all,
I was hoping to embed the svn revision number into my PIC source code.
I have two problems though.

[RF_Developer]

I've been looking into this sort of "watermarking" problem and while I've not yet tried to get anything working, there is a way of doing some useful things.

In Options->Tools there is a list of User Defined Tools. These are command lines tools that run at specifed event. The relevant events for this are "Before Build" and "After Build". These, hopefully (as I've not yet tried it in anger) allow a user script or command line tool to be run before and after all builds. Typically you'd put the svn check-in and immediate read back in the before build script, and that would update the revision number, so no need for adding 1 or whatever. This is especially useful when you're dealing with several code modules as each has its own revision code, and the project as a whole has a different rev code.

In other IDEs (specifically Keil uVision 3 for ARM) the team I headed used the "After Build" event to add a CRC calculated from the hex image with which the code could check itself at runtime. We also marked debug/development builds (unlike the PIC the ARM doesn't need debug handler code) by not giving them a CRC. So builds could identify themselves as dev or release.

This doesn't solve the "getting rid of the $Revision" issue of course. As far as I can see the pre-processor (integrated into the compiler and not an actual separate pass) won't string slice/index so that's not possible at compile time, only as run time. In other words you have to assign your ver_str to a string in ram and extract the relevant bits in code. Messy and wasteful on memory, but I can't find any other way to do it :-( I've already had to do that for compilation dates and time, which I encoded into a 32 bit Timecode; at runtime of course. I needed a timecode as it was for sending over CAN with its max 8 byte messages. Thinking about it, you could get your "Before" script to extract the number for you into a place holder define. That should work.

I hope this helps. As I say I've looked at this, but not yet implemented it, mainly as getting a Subversion server up and running is proving to be politically tricky :-(

RF Developer.

[RF_Developer]

PS: Before and After Build events only work for *builds*! Compiles, including F9s, don't appear to trigger the scripts. Also the Before doesn't appear to wait for the spawned process to finish. That negates the whole purpose of the event.

[mds]

Yes it is all a little messy and Im amazed it has not been "dealt" with previously. Im also amazed at the lack of responses to the post as I was expecting it to be something that everyone would be up against...But then tis said I live on a different planet.

I did look at those script triggers and yes its build not F9 and strange things happen.

I know its code, thus takes up PIC mem and cpu cycles on power up. But its the simplest solution I came up with. I dont always commit after a compile(F9) sometimes its little text changes or I want to try b4 I commit. So the system below works for me.

do{
change code
compile
test // Code reports as 1ver in front of commit
}While(not happy with code)


commit // commit version now matches hex

snip of my define header file

[newguy]

[SherpaDoug]

When I worked for Benthos, now Teledyne, the IT people insisted we use some version control software none of us understood or trusted. It was worse than having nothing at all as we each then used our own individual backup system nobody else knew about. And my boss insisted the only "official" copy of the source code was the one on the disk in his filing cabinet! Glad to be out of that racket.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[mds]

Hi new guy,
subdirs etc was the way I worked for years, so I understand exactly where youre at.
Then I started getting numerous projects, numerous releases of said projects and more than one person working on it, the projects involved firmware,hardware, manuals, CAD.... it became a nightmare to keep track of. I swallowed hard and went looking.
TortoiseSVN solved most of the problems and didnt need a guru. There is no way I would ever go back to folders now.

the only real copy is the one in the filling cabinet... how true!
and that filling cabinet is on a server and pointed at by SVN ;)

Each to their own I recognise its not everyones cupa.

[barryg]

I used a slightly enhanced version of the "subdirs" for many years. Namely, a *.zip file of those subdirs This works well if you do everything yourself, and on one computer. We got into svn about 6 years back. And I'd say it is slightly better than the zip solution. It's nice that it doesn't store endless copies of things that don't change. It's nice, now that I have a work machine, a home machine, and a netbook, and I can't remember which one has the latest version, that svn can keep it sorted. It's nice that the repo is on another computer, thus serving as an independent backup. And it's nice that I can go back and find "the code that was used for that demo a year and a half ago", though admittdly, the zip solution can do that, too. svn has a lot of nice potential features, but unfortunately, I don't know much about configuration management. Having svn does not magically turn me into one.

As to the original issue, I am content that the number changes each time I commit. That way I can tell if I'm running the same thing or not. When I had manual build codes, I never remembered to change them. Now they change by themselves. Your situation probably demands tighter and more accurate control. I depend on my comments in the svn log (or stuff copied to a tag) to identify significant changes.

[RF_Developer]

I don't think that its worthwhile or productive getting into the argument about whether Subversion of things like it are the right thing to use. All I will say is that where I've used such things it's been worthwhile, for a number of often at the time seemingly arcane but in reality very much practical reasons.

One issue with the "commit, fudge numbers, compile" sequence is that technically the code you've compiled is not the code you've commited. Afer fudging teh numbers, the difference may be small or nothing, but its there all the same, particularly if the svn inserted stuff is actually used in live code, as against merely being in comments. The "commit, readback, compile" sequence is better as it avoids fudging and it compiles the actual committed code. Its what it says in the tin.

There is no need to commit every compile. Any pre-build script can ask the user whether they want a development build (not committed) or release (commited), or whatever distinction fits best in your workflow. In our case a release also generated a pdf report showing the times, dates, issues and latest labels/comments/changes of all included files. That involved a database and was quite a lot of work, but we cut the release process from about 5 hours down to less than 5 minutes, and it was more accurate and reliable as it removed most sources of human error and way less of a PITA.

Its difficult to persuade many folks that these things are worthwhile, but as has just happened here, stuff happens: I've spent days trying and failing to track down source for a release of code that now only exists as a hex image - code that is essential for a repair/fault rectification. Its not my code. It's my predecessor's. He was a firm "subdir" guy, but he simply didn't bother to stash everything away, and then renamed hex images, often making it impossible to pin it down to the source from which it came :-(((!

I too naively thought many folks would have come up across this problem. But no, they appear to be mainly stuck on very basic problems such as making serial ports work, and this sort of thing is like looking after our own ivory towers. Ah well.

I don't think the CCS IDE is upto this. Running CCS in MPLAB, which has some very basic svn integration built in, is another possibility, but that has its own problems and I otherwise far prefer the CCS working environment.

RF Developer.