CODEWITHSUNDEEP
git
Amir Saniyan
Amir Saniyan

Reputation: 13759

GIT: Should I commit output files (like *.exe, *.lib) when project in a stable revision?

Version 1.0 of my project builds in Visual Studio 2008 successfully, But when I upgrade Visual Studio to version 2010, building my project failed (for some reasons).

My project changed and new release is ready (Version 2.0). It builds on Visual Studio 2010 successfully.

Now, if I want to access "my-project-version-1.0.exe", I should checkout version 1.0, install Visual Studio 2008 and build it by Visual Studio 2008. I can't build it by Visual Studio 2010.

I didn't commit any output files of my project.

Should I commit output files (like *.exe, *.lib) when project in a stable revision to access older versions of my project in next times?

Is there any better idea?

Upvotes: 3

Views: 3239

Answers (4)

carpat
carpat

Reputation: 869

We put binaries under version control. They are in a separate directory from the code, and we have our cmake scripts copy the binaries to/from the directories they are output to.

The /src/ directory has an external link to /bin/, so anyone checking out /src/ automatically gets the binaries. The cmake scripts then copy the binaries from /src/bin/ to /build/debug or /build/release (for Visual Studio). After compilation, the updated binaries are copied back to /src/bin/

I can make a change in something low-level, compile, commit, and when a coworker updates, they don't have to recompile my code when they are working on something several layers up.

Upvotes: -1

Shahbaz
Shahbaz

Reputation: 47553

Putting non-source files under version control is generally not a good idea. If you insist, you can add it in one commit, and remove it in the next one, and tag that commit.

What you can do however, is to keep the executables separately. For example if you use github, you can upload files so that you can download them later, for example already compiled executables or libraries.

Upvotes: 5

Jes
Jes

Reputation: 2778

The best idea would be to make it work in Visual Studio 2010.

I personally, and in all professional contexts I work in, prefer to keep compiled files out of the repository. Binary diff just doesn't make sense.

Instead keep a backup of all versions outside the repository (or in another repo), so your source code is kept cleanly separated from your compiled files.

Upvotes: 2

Igor Popov
Igor Popov

Reputation: 10113

You should have continuous integration set up so when you have a stable version there will always be an artifact published (executables, documentation etc) for it.

For more info look for jenkins.

Just a note: the repository is just for source code and all the other files that can be used to generate the executables. You should generally avoid putting executables in the repository.

Upvotes: 3

Related Questions