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:
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:
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 Subversion repository — abbreviated SVN repository — is a database filled with your code, files, and other project assets. A SVN repository maintains a complete history of every change ever made.
SVN stands for Subversion. So, SVN and Subversion are the same. SVN is used to manage and track changes to code and assets across projects.
A Subversion working copy does not contain the history of the project, but it does keep a copy of the files as they exist in the repository before you started making changes. This means that it is easy to check exactly what changes you have made.
SVN Access Manager is a powerful tool for managing access to subversion repositories. The tool provides user and group management and access rights (read /write) to dedicated paths in a repository as well. SVN Access Manager uses projects to give users the rights to manage their own modules in a repository.
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"
Why does the source for the library have to exist in the program tree. Compile your libraries separately and link them into your programs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With