views:

183

answers:

2

We are trying to restructure our SVN repository and include a lib folder under the trunk to house assemblies that the project depends on.

I am curious to know how you guys are dealing with shared assemblies? Do you have multiple copies of them that span across different trunk lib folders? Do you have some kind of build process that will automatically update the lib folders when that assembly is built?

How do you guys handle it where you are at?

Thanks!

+1  A: 

For different repositories sharing the same libs, I use an external reference to the repository hosting the libs so that they all share the same code. If within the same repository there are multiple projects that need the libs to compile, then the build process copies from a top-level libs folder to each projects sub-folder as necessary.

RedFilter
+1  A: 

We version all our core libraries.

So e.g., the SVN looks like this:

/repo/lib1/trunk/

/repo/lib1/tags/1.0

/repo/lib1/tags/1.1

/repo/lib1/branches

...

This avoids the situation where you break BC, or something, and it requires an update to the other three projects that use the library.

Further more, we utilize svn:externals to link these libraries into projects.

/repo/project1/tags/1.0

/repo/project1/trunk/library

...

svn propedit svn:externals /repo/project1/trunk/library

Enter the following:

lib1 svn://host/repo/lib1/tags/1.1

... and commit the change.

Project1 itself follows the convention (tags for releases, etc.) as well.

Depending on the language of your choice, there are of course other options. Let me know if you can go into detail and I see if I can extend my answer. But all in all, it's as simple as that. No other build tools required.

We do all our deployment straight from subversion (through capistrano). It's basically just checking out the tag, and done. Even allows hot-fixing it. If you allow me pimping my own blog -- I've written extensively on this topic ("deployment from svn").

HTH!

Till