Version control

Hi All,

Question about version control (subversion and TortoiseSVN):

Should I make the outputs of my compiler versionable (e.g. bit files, hex files, jed files etc). Reason is that if I want to revert back to a previous version and just get the bit or jed file I'd have to recompile. Maybe the tool set might have changed since then, which would require re-installing the previous version when all I wanted was the jed file and the sources that went with it. Does this make sense?

Mark.

Reply to
markp
Loading thread data ...

Today a CD is cheap. You can burn the output files onto CD and keep them in a safe place along with the source code that made them.

If you change a tool, you should roll the version so that you don't end up with two different binary results with the same version.

If the software is very important and needs to be maintained for the long run, you should archive all the tools used along with the source code. The makers of the tools do from time to time add new bugs. In the case of the Microsoft devlopers studio, you really need to achive the entire machine. There is no way of knowing which files will effect the output.

This is also an argument for not using software tools that have finite licenses. If the software will rfuse to run next year, you may not be able to run the current version your only option will be the latest version which means you may not be able to recreate your project.

Reply to
MooseFET

In my humble opinion, it makes perfect sense to save the compiler outputs and any other pertinent binary files, especially when such files have been used a product that has been delivered to a customer.

Having the original binary files has saved my backside on several occasions. I even recall one time that I had to reverse engineer an s-record to get the machine code and then re-interpret this back into the original source code in C, just to be able to match the original files. Had I saved everything properly, I would have avoided several days worth of grueling effort.

Unless you are really strapped for storage, I see little reason to not save them.

Reply to
Noway2

I always keep the compiler outputs (.jed .hex .whatever). Suppose I want to do some more work on an old project (fix a bug, add a feature, use as starting point for a new project). For step one I always recompile the "baseline" unchanged source code, and compare the newly compiled output files against the archived baseline output files. They ought to match, exactly bit for bit. If they don't, it may mean I don't have the right version of the source code, the compiler has changed, the libraries has changed, an include file changed, or something broke. If (or when) they do match, it gives you a good warm feeling and rules out lots of hard to troubleshoot problems. Some comilers embed a time and date stamp in the output files. In which case you get a small (6 to 12 byte) difference but everything else matches up.

David Starr

Reply to
David Starr

Never, ever - It will quickly bloat the version control database to unworkable size!

Version the tool set and the build environment. @work we use a "buildhost" - which is a Linux install for the build in a "chroot" filesystem - the entire buildhost is versioned and checked in because Linux is a bit naughty with what lib's get used. Maybe you can get along with less?

Reply to
frithiof.jensen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.