Hello all,
I have been lurking for quite some time and have searched the
archives but am still perplexed as to the best way to handle source
that is used across multiple projects.
As svn:externals only work currently with absolute URLs I decided
that there is no downside to multiple repositories, especially as the
common source doesn't change that often. The book recommends using a
svn:externals property pointing to a specific revision of the common
code and this is an excellent idea for stable/release builds.
However, I have determined that there are problems with this approach
and I am wondering what other people are doing to get around these
problems.
Before we get into the meat of the problem, let me document the
repository structure I have set-up:
file://svnreps/
common <- repository for common code
common.h <- common header
common.c <- common source
project <- project repository
trunk
common <- svn:externals -r1 file://svnreps/common
main.c <- source file that uses common.h
branches
tags
Initially this looks like exactly what I want and if I check out
file://svnreps/project I end up with the current revision of main.c
along with revision 1 of common.h and common.c in the common folder.
However, the common files are just regular files and if I change them
and attempt to check in (assuming there are other revisions of the
files) I end up with something like:
[monster:~/product/common] nick% svn commit
Sending common.h
svn: Commit failed (details follow):
svn: Out of date: 'common.h' in transaction '4-1'
which makes sense because the file common.h is out of date. However,
if I then do an update inside the common folder:
[monster:~/product/common] nick% svn update
GU common.h
Updated to revision 4.
it looks like common.h gets updated to the current revision which is
not what I think should happen. Why did it get updated to revision 4
when it is in a folder that is set to use via svn:externals revision 1 ?
So I made a change to the common.h again and attempted to commit again:
[monster:~/product/common] nick% svn ci common.h -m "does this work"
Sending common.h
Transmitting file data .
Committed revision 5.
which commits another revision. However, if you return to the top
level of the project source and do an update, common.h gets replaced
by revision 1. Things are not all bad however because the revision
did get committed to the common repository correctly.
So am I doing things incorrectly ? How do other people handle this
issue ?
Thanks,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 31 20:08:31 2006