Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Let's say I have a build. I need to know if a particular changelist/commit is present in that build.

How would I solve this problem?

I can think of a couple of possible approaches:

1) Add the changelist number into the binary so that I can look somewhere in the GUI and know what the changelist number is. I can then use this information to determine if the change I'm interested in is within that build.

2) Tag version control using some string that uniquely identifies that build. What unique string would I use?

Is either of these two better? Are there any other better approaches?

The solution would have to work for both Mac and Windows builds.

share|improve this question
This depends on the version control system and your workflow. –  Daenyth Sep 26 '12 at 2:07
add comment

3 Answers

up vote 2 down vote accepted

Most change control systems uniquely identity each modification/commit/check-in. For example, subversion has the revision ID and git has the commit hash. Either branch/tag for each release or record the commit identifier. Alternatively, keep track of a build number in the source code and search through the history/log for a release with that version number. With that, a developer can find the release in the source control system and look at commits preceding that to determine what changes are in a release.

Do not store the change list in the binary. This usually must be updated manually and, therefore, is prone to accidental omissions or copy and paste errors. The change list may also get large. How far back does the change list go? How much information is included in each change? Is it just an number of the issue from the issue tracking or change tracking system or is there more information? Lastly, putting this information in the binary may help an attacker find security vulnerabilities in the product.

Regarding what to tag, tag it with the version number of the release. If the release is a one off, like one containing a change specific to large customer, append the ID of the request in the support system or issue tracking system.

The operating system (Mac or Windows) is usually not relevant.

share|improve this answer
add comment

2) Tag version control using some string that uniquely identifies that build. What unique string would I use?

Are you using a bug tracking system ?

If not I suggest JIRA or Mantis (I prefer JIRA personally, but I also worked with Mantis before and although not as pretty as JIRA it was fine)

Whether it is a bug, or an evolution, the developer(s) should have a bug ticket assigned. The bug ticket has a unique name (say PROJECTX-234). Notify all developers that their comment must contain the name of the ticket the modification relates to. Doing so will allow you to retrieve in your source repository anything that is related to a given change in your application. Searching with the help of the comments should lead to a list that looks like that:

 PROJECTX-234 first commit
 PROJECTX-234 yyy
 PROJECTX-234 xxx 

Also, JIRA itself, and several continuous build tools (such as Jenkins for example) may connect directly to your repository so that any bug ticket is "linked" to the code that has been changed in order to resolve it.

I don't what your build tool is, but for example Jenkins will list for a given build or release the changes that occurred. Moreover, if you add the JIRA plugin to it, Jenkins may write a comment directly in the bug ticket to indicate in which build the bug has been resolved.

Finally, if you don't want to work with a bug tracking system, write a simple Excel file with the tasks you have to perform and choose a unique name for each one. Use that unique name in your commits.

share|improve this answer
add comment

We don't do this in my current company, and I can't really say that I've missed this feature, but in my previous company we did your option (1) by adding to every source file:

static const char* fileId = "$Id: $";

Most revision control systems support some kind of form of tags that automatically get filled in when the file is checked in, so as soon as the file would get into source control, that tag would automatically be changed to:

static const char* fileId = "$Id: Utility.cpp; rev 6; last check-in 5/2/2012 by so-and-so $";

The format of the string is made up as I don't really remember what it looked like, but you get the idea. When a binary was built from these source files, you could always run

strings app_name | grep Utility.cpp

This would give you the exact revision of Utility.cpp that went into building that binary. (It's also been 8 years since I touched unix command line, so please don't hold it against me if I didn't get the command line exactly right, the idea is there).

While we could certainly do it in the company I work for now, I think we never had the need for this technique simply because once you get a stable and reliable build process going, you can simply take a look at the version number of the binary and you know exactly which file revisions went into making that.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.