1

Possible Duplicate:
Storing third-party libraries in source control

I'm currently starting a project which is going to be developed on a few different computer and I'm keeping in sync with bzr. In the project I'm using a couple of 3rd party libraries, like SDL. In the past I've just pushed a copy of the compiled library to my version control, but that usually seems to massively inflate the size of the branch and generally seem like a bad idea.

Is that the normal practice, just pushing the required libraries, or is there a better way of added libraries to distributed version control like bzr or git? (I know on svn you can use svn:external to do something similar to this)

Community
  • 1
  • 1
m0tive
  • 2,796
  • 1
  • 22
  • 36
  • 3
    Duplicate of [Storing third-party libraries in source control](http://stackoverflow.com/questions/49196/storing-third-party-libraries-in-source-control) – James McNellis Jun 08 '10 at 00:12
  • 2
    The answer to this question is substantially different when using a DVCS like git or bzr (as this question asks) and a "traditional" client-server solution like Perforce or Subversion (as is asked and answered in that referenced thread). – dash-tom-bang Jun 08 '10 at 01:41

2 Answers2

1

Use git subprojects, and either reference from the 3rd party library's main git repository, or (if it doesn't have one) create a new git repository for each required library. There's nothing reason why you're limited to just one git repository, and I don't recommend you use somebody else's project as merely a directory in your own.

Ken Bloom
  • 57,498
  • 14
  • 111
  • 168
  • Using separate repositories for the libraries seems the way to go. I don't think bzr can do subprojects though... maybe I should give in and switch. – m0tive Jun 08 '10 at 20:49
1

what we do, is have each client with its own copy of the library, and configure each IDE individually. Then we install a "dependencies patch" whenever the technical director changes things around.

Ryan Rohrer
  • 599
  • 1
  • 8
  • 16