Question

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?

Was it helpful?

Solution

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"

OTHER TIPS

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top