views:

1134

answers:

2

I'm responsible for several (rather small) programs, which share a lot of code via different libraries. I'm wondering what the best repository layout is to develop the different prorgrams (and libraries), and keep the libraries in sync across all the programs.

For the sake of argument let's say there are two programs with two libraries:

  • Program1
    • Library1
    • Library2
  • Program2
    • Library1
    • Library2

Naturally, bug fixes and enhancements for the libraries should (eventually) merge to all programs. Since the libraries are being worked on while working on the different programs, using externals definitions seems out of the question.

So I thought to treat my libraries at all but one place as vendor branches but I'm not sure what the best layout for this would be.

I was thinking something along the lines of:

  • Libraries
    • Library1 (ancestor)
    • Library2 (ancestor)
  • Program1
    • Program1 code
    • Library1 (vendor branch)
    • Library2 (vendor branch)
  • ...

Then say when developing Program1 some changes are made for Library2, I merge them back to the Libraries part of the repository, and merge them from there to all other programs when desired.

Merging to the other programs can't always happen immediately, the people working on Program2 could be close to a release and rather finish that first, create a tag, and only then update all libraries.

I'm a bit concerned this will result in many merges and a bit of a maintenance headache after a while but I don't really see a much better solution.

Then again, this seems a rather common use case to me, so I thought I'd just ask the stackoverflow community, what's the best repository layout to achieve this?

A: 

Why does the source for the library have to exist in the program tree. Compile your libraries separately and link them into your programs.

Steve Moyer
Libraries are being developed while working on the programs...
Pieter
Okay ... so you have a tagged release of a library that is NOT the development trunk and that's what you link against your program.
Steve Moyer
+7  A: 

Well, I guess I disagree that externals are out of the question. I've had a similar problem in the past. I solved it using the svn property externals.

Create your library repositories:

svnadmin create /path/library1
svnadmin create /path/library2
...

Create client repositories:

svnadmin create /path/program1
svnadmin create /path/program2
...

Now declare the libraries as external within the program repositories:

cd /path/program1
svn propset svn:externals "library1 svnpath://wherever/library1/trunk/" .
svn propset svn:externals "library2 svnpath://wherever2/library2/trunk/" .

Now then you can make changes to programs 1 & 2 and making commits at the root of those projects doesn't affect the libraries... but, if you needed to make changes to the libraries you can. Then if and only if you have write permissions to the library repositories you could commit those changes too - but only from the library's subdirectory.

I.e. this doesn't make a commit to the libraries...

... make a change in /path/program1/library1 ... 
cd /path/program1
svn commit -m "some change"

This commits the change made in the library above:

cd /path/program1/library1
svn commit -m "change to library code"
ceretullis
Thanks for the clear, elaborate answer, but wouldn't this force all changes to the libraries to all programs? Programs should be able to "hang on" to an older version for a while if desired (while others should be able to happily commit and work on of course)Clarified the question a bit more.
Pieter
Pieter, no making changes to the libraries doesn't force the changes to all programs. If you need to 'hang on' to an older version of a library setup the external to be a tagged version (or a specific version using --revision). Even if you checkout the trunk, the changes don't have to be pushed up.
ceretullis