Connect with us

Version control

Discussion in 'Electronic Design' started by markp, Apr 5, 2007.

Scroll to continue with content
  1. markp

    markp Guest

    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?

  2. MooseFET

    MooseFET Guest

    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.
  3. Noway2

    Noway2 Guest

    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.
  4. David Starr

    David Starr Guest

    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
  5. Guest

    Never, ever - It will quickly bloat the version control database to unworkable
    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?
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day