33

I've met quite a few people lately who says that 3rd party libraries doesn't belong in version control. These people haven't been able to explain to me why they shouldn't yet, so I hoped you guys could come to my rescue :)

Personally, I think that when I check the trunk of a project out, it should just work - No need to go to other sites to find libraries. More often than not, you'd end up with multiple versions of the same 3rd party lib for different developers then - and sometimes with incompatibility problems.

Is it so bad to have a libs folder up there, with "guarenteed-to-work" libraries you could reference?

CJBS
  • 15,147
  • 6
  • 86
  • 135
cwap
  • 11,087
  • 8
  • 47
  • 61
  • 1
    Are you talking about adding the code or compiled binaries for the libraries? – Eric Nicholson Nov 10 '09 at 18:18
  • Compiled binaries mainly - but I see no reason to not apply the same to the code if it's feasable. – cwap Nov 10 '09 at 18:22
  • 1
    possible duplicate of [Storing third-party libraries in source control](http://stackoverflow.com/questions/49196/storing-third-party-libraries-in-source-control) – user Jun 05 '14 at 11:51

12 Answers12

22

In SVN, there is a pattern used to store third-party libraries called vendor branches. This same idea would work for any other SVN-like version control system. The basic idea is that you include the third-party source in its own branch and then copy that branch into your main tree so that you can easily apply new versions over your local customizations. It also cleanly keeps things separate. IMHO, it's wrong to directly include the third-party stuff in your tree, but a vendor branch strikes a nice balance.

rmeador
  • 25,504
  • 18
  • 62
  • 103
  • Didn't know about vendor branches. Neat link :) – cwap Nov 10 '09 at 18:21
  • my preferred choice - even if it might not always work in complex environments (there might be too much dependencies to download) – axd Dec 25 '22 at 17:59
17

Yes you should (when feasible).

You should be able to take a fresh machine and build your project with as few steps as possible. For me, it's:

  1. Install IDE (e.g. Visual Studio)
  2. Install VCS (e.g. SVN)
  3. Checkout
  4. Build

Anything more has to have very good justification.

Here's an example: I have a project that uses Yahoo's YUI compressor to minify JS and CSS. The YUI .jar files go in source control into a tools directory alongside the project. The Java runtime however, does not--that has become a prereq for the project much like the IDE. Considering how popular JRE is, it seems like a reasonable requirement.

Michael Haren
  • 105,752
  • 40
  • 168
  • 205
  • 1
    This also means that you always have a working version of the 3rd party library with your code - what if it's development is discontinued or if it is updated and breaks compatability? – deanWombourne Nov 10 '09 at 19:53
  • 1
    Then it won't be updated, only the working version if still used will be checked in. – Alex Shnayder Oct 26 '10 at 12:32
  • @Alex, true--though I think that's a feature. I generally don't want my tight dependencies to change from user to user automatically or accidentally – Michael Haren Oct 26 '10 at 13:11
  • Expediency for building is important, but it is for dependency management as well. Tools to manage dependencies (in the java world: ant/ivy, maven, gradle) make management of dependencies easy. Checking 3rd party dependencies not only populate your repository bigger than it needs to be, it makes it harder to remove old versions of 3rd party depencies to add new versions (ie, dependency management). – dsummersl Jul 09 '13 at 13:58
17

Another reason to check in libraries to your source control which I haven't seen mentioned here is that it gives you the ability to rebuild your application from a specific snapshot or version. This allows you to recreate the exact version that someone may report a bug on. If you can't rebuild the exact version you risk not being able to reproduce/debug problems.

Drew Sherman
  • 887
  • 2
  • 6
  • 8
8

No - I don't think you should put third party libraries into source control. The clue is in the name 'source control'.

Although source control can be used for distribution and deployment, that is not its prime function. And the arguments that you should just be able to check out your project and have it work are not realistic. There are always dependencies. In a web project, they might be Apache, MySQL, the programming runtime itself, say Python 2.6. You wouldn't pile all those into your code repository.

Extra code libraries are just the same. Rather than include them in source control for easy of deployment, create a deployment/distribution mechanism that allows all dependencies to easily be obtained and installed. This makes the steps for checking out and running your software something like:

  • Install VCS
  • Sync code
  • Run setup script (which downloads and installs the correct version of all dependencies)

To give a specific example (and I realise this is quite web centric), a Python web application might contain a requirements.txt file which reads:

simplejson==1.2
django==1.0
otherlibrary==0.9

Run that through pip and the job is done. Then when you want to upgrade to use Django 1.1 you simply change the version number in your requirements file and re-run the setup.

Andy Hume
  • 40,474
  • 10
  • 47
  • 58
  • Thanks for another point of view :) – cwap Nov 10 '09 at 18:28
  • I'm frmly in the 'it belongs in the VCS' camp, but you have a good point. Perhaps keeping everything that goes into your release in source control is the best guideline. If you're distributing a webapp which requires Pyton & MySQL they don't belong in source control. – Kristof Provost Nov 10 '09 at 19:29
  • Completely agree with Andy, but would venture to throw the bone that 'release distributions' (your code, bundled with all its dependencies) make perfect sense when handing off to developers/users not committing to your project. – dsummersl Jul 09 '13 at 14:01
  • If you are not going to keep track of changes on 3rd party software, you should not have it. – jgomo3 Oct 10 '14 at 21:06
4

The source of 3rd party software doesn't belong (except maybe as static reference), but the compiled binary do.

If your build process will compile an assembly/dll/jar/module, then only keep the 3rd party source code in source control.

If you won't compile it, then put the binary assembly/dll/jar/module into source control.

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • 1
    What if the third party software happens to be e.g. the SGI STL implementation, or the Boost library? These consist of sources. Your first statement is somewhat too strict, imho. – xtofl Nov 10 '09 at 18:20
3

This could depend on the language and/or environment you have, but for projects I work on I place no libraries (jar files) in source control. It helps to be using a tool such as Maven which fetches the necessary libraries for you. (Each project maintains a list of required jars, Maven automatically fetches them from a common repository - http://repo1.maven.org/maven2/)

That being said, if you're not using Maven or some other means of managing and automatically fetching the necessary libraries, by all means check them into your version control system. When in doubt, be practical about it.

dustmachine
  • 10,622
  • 5
  • 26
  • 28
2

The way I've tended to handle this in the past is to take a pre-compiled version of 3rd party libraries and check that in to version control, along with header files. Instead of checking the source code itself into version control, we archive it off into a defined location (server hard drive).

This kind of gives you the best of both worlds: a 1 step fetch process that fetches everything you need, but it doesn't bog down your version control system with a bunch of necessary files. Also, by fetching pre-compiled binaries, you can skip that phase of compilation, which makes your builds faster.

Russell Newquist
  • 2,656
  • 2
  • 16
  • 18
1

You should definitively put 3rd party libraries under the source control. Also, you should try to avoid relying on stuff installed on individual developer's machine. Here's why:

  • All developers will then share the same version of the component. This is very important.
  • Your build environment will become much more portable. Just install source control client on a fresh machine, download your repository, build and that's it (in theory, at least :) ).
  • Sometimes it is difficult to obtain an old version of some library. Keeping them under your source control makes sure you won't have such problems.

However, you don't need to add 3rd party source code in your repository if you don't plan to change the code. I tend just to add binaries, but I make sure only these libraries are referenced in our code (and not the ones from Windows GAC, for example).

Igor Brejc
  • 18,714
  • 13
  • 76
  • 95
1

We do because we want to have tested an updated version of the vendor branch before we integrate it with our code. We commit changes to this when testing new versions. We have the philosophy that everything you need to run the application should be in SVN so that

  1. You can get new developers up and running
  2. Everyone uses the same versions of various libraries
  3. We can know exactly what code was current at a given point in time, including third party libraries.
MightyE
  • 2,679
  • 18
  • 18
  • 1
    For your 3 points, there are manifest files and automated scripts for scaffolding your Dev-environment. Source Control should not be used to solve a distribution and deployment problems. It should be used to track changes you do to source. If you ever make a change to a 3rd party software, then you should do it. – jgomo3 Oct 10 '14 at 21:12
  • The job I was in when I wrote this post, we were working in technologies where there aren't accepted general purpose distribution platforms and scaffolding available at the time, we engaged in the SVN Vendor Branches pattern (http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html). This really is just a way to use source control as a distribution solution so you don't have to build that kind of infrastructure from scratch. Note that my comment that you're responding to there is 5 years old; tools like NPM were still fledgling. – MightyE Oct 26 '14 at 15:28
  • I'm not sure anymore about this subject. I though that studying good software source code i could get an answer, but you see both strategies, for example: Apache httpd[1], keeps a 3rd party clean source code, but git[2] includes a 3rd party library (xdiff). [1] http://svn.apache.org/repos/asf/httpd/httpd/trunk/ [2] https://github.com/git/git – jgomo3 Oct 27 '14 at 20:29
1

No, it isn't a war crime to have third-party code in your repository, but I find that to upset my sense of aesthetics. Many people here seem to be of the opinion that it's good to have your whole developement team on the same version of these dependencies; I say it is a liability. You end up dependent on a specific version of that dependency, where it is a lot harder to use a different version later. I prefer a heterogenous development environment - it forces you to decouple your code from the specific versions of dependencies.

IMHO the right place to keep the dependencies is on your tape backups, and in your escrow deposit, if you have one. If your specific project requires it (and projects are not all the same in this respect), then also keep a document under your version control system that links to these specific versions.

Bernd Jendrissek
  • 1,088
  • 6
  • 15
0

I like to check 3rd party binaries into a "lib" directory that contains any external dependencies. After all, you want to keep track of specific versions of those libraries right?

When I compile the binaries myself, I often check in a zipped up copy of the code along side the binaries. That makes it clear that the code is not there for compiling, manipulating, etc. I almost never need to go back and reference the zipped code, but a couple times it has been helpful.

Eric Nicholson
  • 4,053
  • 1
  • 28
  • 29
0

If I can get away with it, I keep them out of my version control and out of my file system. The best case of this is jQuery where I'll use Google's AJAX Library and load it from there:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>

My next choice would be to use something like Git Submodules. And if neither of those suffice, they'll end up in version control, but at that point, its only as up to date as you are...

Wes Baker
  • 1,519
  • 1
  • 10
  • 8