[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Shared source best practices

From: Nick Beadman <nicklist_at_xinet.com>
Date: 2006-05-31 20:07:14 CEST

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

Before we get into the meat of the problem, let me document the
repository structure I have set-up:

        common <- repository for common code
                common.h <- common header
                common.c <- common source
        project <- project repository
                        common <- svn:externals -r1 file://svnreps/common
                        main.c <- source file that uses common.h

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 ?


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.