How to debug old versions of software?

Question

Note: Currently using Perforce as a CM tool.

I currently do several debug releases of software [only debug files (.pdb) and binaries (.dll and .exe)]. At every release, I check the all the files used to generate the binaries into our CM tool (baseline). Then I checkout the files and continue making changes. Currently, if there was an issue with one of the releases such that we needed to debug it, I would have to revert the code back to the version used.

My question is, how should I go about easily debugging old versions? If I create a branch from the baseline I just did, then I could easily just build the previous version for debugging, but what about further back than that? I don’t want to branch every time I do a baseline (pretty sure I don’t want to do that).

I know with VHDL you can create builds with test points and use the Xilinx tools to debug any built version of VHDL. Is there a similar way we can do this in VS (maybe using the .pdb files and some external tools)?

How do you go about baselining revisions so that you can easily debug old version?

Answer 1

Eric Sinc has a fantasic Source Control HOWTO that covers this topic (and much more).

I would highly recommend reading it because this guy knows his stuff.

You'd be most interested in Chapter 6: History and Chapter 7: Branches.

This stuff really helped me when I was learning about source control and software release strategies.

Answer 2

warning - been a while for me and perforce:

For perforce, I'd probably go ahead and "Tag" each release (in perforce, tagging files creates a label)

Then you can checkout a tag to debug it. If you need to make changes and push out a "hotfix" against that old version, you can create a branch from that tag rather than from the HEAD.

Tagging is pretty simple, "p4 tag -l release2.0 //depot/bch/..."

Branching from a tag isn't too hard, you need to create a new branch then integrate from the source label: "p4 integrate -b [branchname] -s //depot/bch/[email protected]"

Note that you can tag previous (historical) versions of the code as well, or create branches from previous commits too.

Answer 3

With p4 you don't have to create a branch to go "back in time". All you have to do is sync to the appropriate tag or change number. For instance, if you were to recreate version 1.1 of ProductX, and the last change in p4 was change number 2000, you can do the following:

p4 sync //depot/ProductX/...@2000

or if a tag was used, such as "Release1.1" you can do this:

p4 sync //depot/ProductX/[email protected]

or if you couldn't figure those out, you could even try to sync at a certain date. Such as:

p4 sync //depot/ProductX/...@2009/02/01:12:15:00

For more information in p4 concerning file revisions, try this:

p4 help revisions