views:

77

answers:

7

Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?

+1  A: 

What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.

Chris Missal
+1  A: 

First, you can easily compile/run your program just by checking out your repository.

Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.

Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.

ChrisW
A: 

I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.

The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.

Matthew Manela
+4  A: 

Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.

IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.

Michael
As I usually use eclipse which has built-in compiler, I prefer to put it under VCS.
I have to agree. Builds = Sources + Tools. If you don't have both you don't get a build, and being able to build directly after a sync, even from a fresh machine, is a hallmark of a mature development environment, imho.
fatcat1111
+2  A: 

Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.

Edit: We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.

Russell
+4  A: 

I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.

Russell Steen
A: 

I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.

Pavel Minaev