revisioning and controlling of the software

[blups]

Hi peeps,

I have to ask about the revision(versions) control of your software. Would you recommend me a proper tool (software) for this purpose pls.
We are an young team developers – 4 guys with a total different manner of working and we have urgent need of a new, centralized and systematic method of the developing process.

Greets GR

[RF_Developer]

This forum appears to primarily comprise hobbyists, beginners and students with only a few professionals. As such there appears to be little use of for such tools. I responded to a thread recently in which the use of simple sub-directories on a server seemed to be the most favoured means of software/firmware version control (SVC) in use with CCS.

The CCS IDE offers no integration for any SVC and, poor to the point of probable unusability, support for it. A better option might be to use the CCS compiler from Microchip's MPLAB IDE which *does* provide some SVC integration.

As to which SVC... well as always you pays your money and you take your choice. I've used Microsoft Source Safe 6 in the past, and whilst it worked, I wouldn't recommend it for new processes. Recently I've looked at Git and Fossil. Fossil in particular was a good fit into our company's work patterns, and not just in software/firmware but for entire design and development projects. The trouble is that introducing such a tool would involve massive political difficulties and, frankly, some of the engineers are more fossilised in their ways than the tool! I've eventually fallen back on Subversion as being a more conventional SVC tool to be used for software only. Its free, well supported and reasonably mature, and MPLAB includes integration for it. I have, however been here over a year and so far there's been little to no movement towards getting it up and running. There appears to be no managerial will to "make it so". So I have an educational and managerial mountain to climb.

You are a young company with little or none of the baggage that's holding back my attempts at instituting SVC. You need something that meets your needs, fits into your infrastructure and will scale with the company at is grows. It should also not throttle your development process or significantly cramp your development style. Yet also you must understand that it will necessarily impose some constraints and overhead on development.

The only SVC I have available to me at present is the "server directories" type thing. CCS is slow when run in such an environment as it cannot (read as "I haven't yet found a way") run with output and intermediate files in a different directory tree from the source. You cannot have sources on a network drive (as mine currently must be) and the project on a local drive (which is what I would like). This is due to CCS's poor handling of absolute/relative paths and inflexibility of project handling, i.e. it doesn't have independant paths to source, intermediate and output files as do many other IDEs. The result is painfully slow compilation which is particularly crippling when live debugging. A SVC would at least allow me a local working directory, and hence faster compilation and improved and far less frustrating development cycles. It'll be worth it for that alone! I do not know if MPLAB is any better in this respect.

Also SVC on its own is not the whole story. There is another issue to be dealt with, for which, currently, there is no off the shelf tool. I call this issue "watermarking", or the version identification and reporting of compiled code. This came to the fore in a previous job I had, developing ARM code. There, as with all the projects I've done since, and most before, the final image was derived from many source elements; code, headers and so on. SVC will keep track of the version numbers of the various source files for you. That's all fine and dandy, and you need to version number the project as a whole. Yes SVC can do that for you too. BUT you also need to version number the final produced image. I.e. the only version number/code the user and other see, AND you need to tie that to the versions of the individual source elements. We produced a modest SQL database based tool that managed the release process, checking in all the source elements, getting their SVC versions and change related comments, reporting them in a PDF release note along with the newly created image version number which it wrote to a place holder in the code before compilation. After compilation/build, it also, as an additional safeguard and identification check, CRCed the code in a way that the running code could reproduce from the program memory and added that to the hex image. That way released code could be identified by its reported version numbers AND could check itself for by the CRC which was also (fairly) unique to each build. Development builds, i.e. not releases, were not source controlled, had no CRC, no release report, and an obviously different version number (that started with "D") thus could easily be identified as "not released". Dev builds were faster and obviously much more frequent. Release candidates for regression and other testing were simply the last development release. If testing was successful we simply rebuilt the RC code in full release mode. Technically it can be argued that we hadn't tested the release code (as it differed but only in "watermarking" details) but then what is the alternative, testing full-on releases? No, we couldn't do that as releases had to be fully *tested* and believed to be good to go code. It took the release process down from half a day to just five minutes... and got the management off our backs as they were very twitchy about un-released code getting to customers as our production staff, over a hundred miles away with ingrained culture of not talking to development, tended to ignore release instructions and had a habit of searching the server for any code images they took a fancy to...

So, SVC on its own is only part of the story, albeit a big part.

Have fun!

RF Developer.

[Sergeant82d]

I use Subversion, with the TortoiseSVN GUI on my WindowsXP main development machine (in MPLAB and/or MPLABX).

I keep the repository on my NAS. I occasionally use one of five other PCs either at home or away (laptops), and find it extremely useful to know that I can back up to any given revision, or ensure I have the latest revision, at any time, from any computer.

[Ttelmah]

I suspect most of the professionals here, simply have a third party tool, or a little scripting language (as I do), which generates a project version 'tag' and adds it to the CCS code. I use this approach, because it also allows me to add the same tag to the PCB (few packages directly offer this), and keep software/hardware versions in-sync.
I actually find most of the supposed tools to do this annoying with few handling the complexities of perhaps five or six PCB's, twenty sets of firmware for these, software in two or three languages on the control system, all forming a 'version'.
Plenty of people had version tagging before SVC control software came along, and it is relatively easy to maintain something like a spreadsheet, output the version tag as a text file, and just include this into a CCS project.

Best Wishes