On 2/8/2011 2:16 AM, David Aldrich wrote:
Hi
We are developing a fairly large application that uses open source
libraries. We have one svn repo per application. Currently, the open
source libraries are all stored with the application. This is a bad
idea because the working copy and repo are now very large. Also,
every branch gets a copy of all the open source code.
So I propose to move the open source libraries into a separate
repository. We can then reference that code either using externals
or, more likely, environment variables in the build files. I prefer
the latter because then the open source code will never appear in the
project's working copy and we can easily exclude it from branches if
it is not required.
So how should I structure the open source (vendor) library repo? I
was thinking of the following:
OpenSourceLibs
|
|---- Boost
| |---- tags
| |---- trunk
|
|---- wxWidgets
| |---- tags
| |---- trunk
etc.
That way, I can tag each library individually.
We then check out OpenSourceLibs beside the application's working
copy, and specify in the makefiles which libraries to use by
referencing the tags.
My concern is that each developer must correctly checkout and
maintain his/her OpenSourceLibs working copy. It would be best to do
this as a sparse working copy so they only get what is needed, but
that is not easy for the developer to do as I have a repo of projects
of tags i.e. several layers for him to manage. Or they could just
checkout and update the entire OpenSourceLibs folder, but that would
be very large.
Would anyone like to suggest how best to handle this please?
Best regards
David
Sample disclaimer text
We use a structure similar to yours, in the same repository as our other
projects, and we use externals in our individual projects to pull in the
necessary libraries for each project. This has served us very well for
some time.
Mark