Working with repos

When working with repos (I have github in mind), should we also commit third party libraries? For example, boost and poco compile to 5G with samples. Should we upload all that to github? If not, then how do we keep the libraries in sy开发者_开发百科nc with other people?

Sorry about lack of capitalization and grammar. I am on my phone and it is difficult to type.

First rule of version control: never commit generated assets to your repository. So you should definitely not commit build products of Boost and Poco to your repository. Whether to include dependencies in your repository as source is really up to you; it kind of depends on your project, how many dependencies you need, how much of the public for your software is likely to have easy access to those dependencies, etc. Packagers and distributions generally prefer that you don't bundle your dependencies, but instead carefully mention them in a README or INSTALL file.

If you want to make it easy to get the dependencies for people who check your code from a VCS, try to use svn externals, git submodules or hg subrepos, making it easy to exclude the dependencies and establish a clear link to the dependency's upstream repository.

First, it doesn't matter if you're using Maven or not. It doesn't matter.

Now, that I have that out of the way, I suggest you use a Maven repository manager like Nexus or Artifactory.

What Artifactory and Nexus do is create a network wide repository structure for third party libraries.

You can easily download any artifact in your release repository with the standard wget or curl commands. If you use Ant, you can use Ivy to manage your artifacts. If you use Maven, well, you're all set. That means you can script the download of the required third party libraries right in your build scripts.

A release repository can also be used for your third party libraries. Do you produce a base library that other projects of yours use? You can use the same release and download mechanism to make your compiled objects available to your system.

Checking in your third party libraries in causes the following issues:

• The commits are usually done on a project-by-project basis. That means if you have more than one project that depends upon the third party foo library, chances are you'll have foo located in two different places in your repository.
• You will lose information about foo. You won't remember which version of foo it was. I've been a build engineer for java projects for the last decade, and in every project we have some foo.jar from the Foo project, and none of the developers know whether it is verison 1.3, 2.5, or 4.5. We have no idea if the Foo project even supports this older version or if we got the buggy 1.3 and should have upgraded to version 1.4 back in the Hoover administration.
• Binaries take up lots of room in your source repository. Every time you commit a new version, it's even more room. And, what does it get you in return? Not much. You can't diff it to see what was changed in the previous version. Checkouts can take forever with no benefit in return.
• Many source repositories won't allow you to remove obsolete versions of your third party programs. I won't mention any names (cough! Subversion! cough!), but I've seen repositories that are 100 to 200 gigabytes in size, and it's almost nothing but obsolete versions of third party libraries.

By the way, you never mentioned your programming platform. If you are using Ruby, Php, or Perl, you can use their built in repository system (Gem, Pear, and CPAN respectively) and you won't need to worry about configuring release repositories.

I like it when those third party libraries are available via git, and I can include them in my project as submodules. I like that a lot. Makes pulling in updates a total piece of cake.

When that's not possible, then yeah, I include their code right in my repo. Ultimately, I'm going to turn my production branch over to my operations people to push to the production server, so it needs to have all the goods needed to run. That may be a different workflow than yours, but that's how mine works.