Maker Pro
Maker Pro

Version control

M

markp

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.
 
M

MooseFET

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?

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.
 
N

Noway2

markp said:
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.
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.
 
D

David Starr

markp said:
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.
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
 
markp said:
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).

Never, ever - It will quickly bloat the version control database to unworkable
size!
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?

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?
 
Top