views:

36

answers:

3

I want to keep dependencies for my project in our own repository, that way we have consistent libraries for the entire team to work with. For example, I want our project to use the Boost libraries. I've seen this done in the past with putting dependencies under a "vendor" or "dependencies" folder.

But I still want to be able to update these dependencies. If a new feature appears in a library and we need it, I want to just be able to update that repository within our own repository. I don't want to have to recopy it and put it under version control again. I'd also like for us to have the ability to change dependencies if a small change is needed without stopping us from ever updating the library.

I want the ability to do something like 'svn cp', then be able to 'svn merge' in the future. I just tried this with the boost trunk, but I'm not able to get any history using 'svn log' on the copy I made.

How do I do this? What is usually done for large projects with dependencies?

A: 

Have you looked into SVK? It builds distributed features like the ones you're asking about on top of svn.

Hank Gay
So am I able to use svk with an existing svn repository? If I use svk to create a mirror of another repository, can I still use svn for everything else or do I have to tell everyone to start using svk instead?
Jonathan Sternberg
I don't actually use `svk` myself (I use `git` and `hg` mostly), but [this article](http://svk.bestpractical.com/view/UsingSVKAsARepositoryMirroringSystem) seems to cover the use case you described (unless I'm missing something).
Hank Gay
+2  A: 

You could also consider using the svn:externals property on your dependencies or vendor or third_party directory. Then you could for example set the svn:externals property on your dependencies/boost directory to http://transact.dl.sourceforge.net/project/boost/boost/1.43.0/boost_1_43_0.zip or similar and this will be automatically downloaded into your dependencies directory when you checkout. If you want to upgrade the library then just change the svn:externals property.

krock
A: 

You can stay with SVN. Vendor Branches solves this issue.

Here is the similar topic.

Mr Mulch