Do you keep your build tools in version control?

Question

Do you keep tools that are necessary to build your project under version control?

If you do, what are your guidelines for which tools to include? I guess noone puts Visual Studio in version control, but how about your unit-test-runner? The Nant/Ant/Maven executable?

How about external dependencies? Do you have Boost in version control? The JDK? NUnit/JUnit? Where do you draw the limit here?

(See also this question).

EDIT: I guess my question was not completely clear: I did not want to know whether you kept them in version control vs. or some shared drive. I really wanted to know whether you checked the tools necessary for building a project into version control together with the project, so that when you checked the project out, you would automatically get the tools.

As a general follow-up to those who answer no: what is your process for keeping track of those tools? Do your script download them?

Answer 1

Generally I only add items to version control that are likely to be maintained by myself or someone else I work with. An external library is normally consumed by a project - most projects aren't in the business are re-writing the libraries they depend upon.

I would suggest adding tools that you customize to version control. For everything else, you can just save the packages in a common location. No need to bloat your repository with code that will never change from the standard distribution.

Answer 2

I put build scripts under version control, but not tools. Generally I version files that either part of the core of the application, or are likely to change frequently during the lifetime of the project (and which everyone needs access to those changes). This includes pretty much all configuration files.

Answer 3

We do not - in fact, I've never worked for a place that did.

We do keep things like Makefiles and build scripts and testing scripts in source control, but never ant or C compiler or such.

The reason is, it usually requires more than simple checkout to get the build tool to a usable state, and you need to do some heavy-duty sysadmin job to maintain multiple versions at the same time or switch between versions. So keeping them in source control would solve the tiny part of the problem.

Answer 4

We do not put Tools in SVN that came from outside (Visual Studio, Eclipse, CDT-Plugin, ...).

But we have a big set of self-written tools (code generators, custom build assmeblies for VS, and an Eclipse plugin) where we put the source AND the binaries into SVN.

The reasons for this decision are simple technical:

• Our tools are very small and do not need an explicit setup-routine to run (so a simple svn checkout leaves you with a running set of tools)
• Our tools change more often then the 3rd party tools (so we don't need to tell our developers to update the tools 3 times a month)

Answer 5

Yes, I keep EVERYTHING that is part of the process of delivering a software production in version control.

Answer 6

No, I don't because I use MsBuild, and it's part of .NET framework anyway

Answer 7

I put makefiles, shell scripts, and any code generators I have written in version control. I don't store binary files in version control unless there librarys that cant easily be built from source.

Answer 8

There are two schools of thought on this:

1. Put just your source code into the repository.
2. Put everything someone would need to build your software short of the operating system and language runtime into the repository.

I personally tend more towards #2 because it makes it easier for someone to get up and running with my code. At any rate, I would argue that if you opt for the first method, you should at least make it so that a person can get the things required by point 2 and your source code in one step, even if not necessarily by version control.

Unfortunately, the build system is kind of a grey area. I personally leave it out unless I'm using something obscure or non-standard. And what's obscure and non-standard is dictated by the environment you work in. For example, if your company always uses MSBuild but decided to use Nant for whatever reason on this one project, then I'd include it.

Answer 9

No. Most development shops have a fairly standard set of tools. One idea, though, would be to keep a standard "quick setup" wiki or similar that deep-links to installers for all needed build tools. Write it so that a person with relatively little expirience can easily set up a development machine. A more advanced option would be to keep a standard virtual hard disk containing everything.

We do, however keep everything else in source control- all build scripts, SQL scripts, file dependencies (ie referenced dlls not installed in the GAC or program files) etc.

Answer 10

Yes! is my answer.

I put build tools like NUnit and NAnt in version control.

The main rule for me is:

• The build server has to be able to build the solution.

And the build server I use does not have NUnit, NAnt etc installed.

The build server has got the .NET framework and CruiseControl.NET, and not much else....

Answer 11

I typically work with eclipse/ant on java projects. No, i do not keep the JDK, Ant or eclipse under version control, but:

• all my source
• the build script(s)
• all 3rd party libraries in their used version (yes, also junit)

The reason: i have a nearly self contained build system, any system with a jdk and ant installed will be able to build, without network connection neccecary (package lists for external javadoc also checked in). This can be my macbook, the companies windows desktop, any continious build server.

Answer 12

Not the tool, but the script. We use Ant. The build.xml script that drive the process is under source control.

Answer 13

We went down a different path of setting up a VM on which we make our release builds. This then gets archived (but not into the revision control system for some reason).

So long as we have a machine that can host the VM we can recreate the binaries. Giving us independance from the underlying OS.

There were a few issuses getting the liscence manager up and running, but after that all was good.

Answer 14

We use maven, so we only check in the code, the tests, config files and of course the pom.xml, no libs, no tools.

Answer 15

Personally, I prefer to put as many of the build tools as possible in the repository, but I draw the line at the IDE and the compiler.

I like to think it as a tradeoff: I can choose between:

• Documenting the necessary tools (including maintaining that documentation) and having to install them each time I need to get back to the project (and multiply that by each extra developer on the project)
• Putting the tools in the repository, so they are automatically checked out with the right version.

For something like the IDE, it is easier to just document it, and most developers will have it already installed. For Ant, Nant, JUnit etc. it is easier to include it in the repository.

I especially like having Ant/Nant in the repository, because it allows me to include a go.bat/go.sh-script like this:

set ANT_HOME=tools/apache-ant-x.x.x
tools/apache-ant-x.x.x %*

Then I can always checkout a project, run "go" and it should build the project (assuming I have the JDK/.Net Framework installed).

Answer 16

We are a Maven shop and previously an ANT shop. In the ANT days we would check dependent libraries into the project structure. Now we only check in the resources necessary to build the application (pom, source code, resources, etc) but definitely no libraries.

Answer 17

Code, build, test, documentation and any other automation. I generally even put the schedules and any other project-relevant documentation in the repository as well.

And for most projects, if I have the source for dependent libraries, I usually put those in their own repositories, so I can track changes to them over time.

As for pre-package tools in installable packages, I keep them all in one big directory tree on a accessible server (with the old versions). That way I can point any new developers at the dir and tell them what to install (and know that they have the same versions as the rest of the team). I'd use a repository, but it's overkill, and a shared file-system is easier to access by everyone. The old versions are kept in case of support issues.

Paul.

Answer 18

What goes into our repository:

• Any code I write or any of my students write

• All Makefiles, tests scripts, and things of that ilk

• External tools we have modified (we typically put in the whole tool, not just patches) including Andrew Hume's version of Make

What doesn't go in:

• Source code to all the compilers we're using

• Source for the shell

If we had better tools we would put it all into the repository. For a great book on how to do this and keep track of all versions of everything since the start of time, check out the book on the Digital SRC Vesta project.

Answer 19

We keep 2 repositories: The "fast moving one" contains our code, with branches for releases and patches.

The slow moving one contains 3rd party libraries and tools, including JDK versions. There is no branching or tagging for most of this, as the code in the other knows how to select what it needs. Two versions of the same library are checked in under different names, so both will be available after a checkout. Some of our own cross-release tools are also included in this repository. IDE's are not included, as they are not part of the official build process.

There are two reasons to store tools in some sort of repository:

1. Any developer can easily find the tools they need.
2. A replicate of any official build from the past can be created, so that a patch can be generated.

Answer 20

I'm really surprised by all the "no I don't do this" responses. You can't reliably build the code base unless you have the specific versions of the dependencies that the code was written against. So this would include any DLLs you are referencing like unit testing and mocking frameworks, UI control sets, etc.

A developer should be able to do a checkout and build in just a couple steps. There's places out there where this takes all day.

Answer 21

No. Absolutely not. Never. Your VCS should only house your code. If you want to ensure that someone can quickly install your code, you need to provide a distribution system. Someone who wishes to install your code should be using either a packaged binary distribution or building from a source tarball. They should NOT be building from the VCS. The distribution tarball is the place to put things that are necessary for your project to build but that are either automatically generated or not directly part of your project. It is NOT the place for dependencies, however. If your project needs the boost libraries, it should be stated in the documentation as a dependency and your build should fail if it is not installed. The user building from the source tarball is expected to be able to install the dependency. The user building from the packaged binary distribution is expecting to have the package system deal with the dependency issue. The user building from the VCS (ie, a developer) is expected to install the build tools necessary for your project.