>That looks like it will work. Thanks for the tip. I gather then that
>in the working copy, each project will have its own copy of the
>libraries that many projects share. While these library sources will
>be linked together in the repository, they will need to be
>independently (and explicitly) committed and updated.
I'm not sure... I know svn status from the root of the work area will
report all of the modified files in all subdirectories, but I have not
completed a ci from the root with modified files in external
>this configuration, I gather that when compiling I should reference
>the libraries within the project rather than the libraries that are
>siblings to the project.
Not sure I understand this question...
I use relative paths for my includes and lib links, so in the example
Projects\Note may have an include path of ..\..\common and link with a
lib from ..\..\resources\
>I'm very new at organizing these things. Is this the typical way of
>doing it then?
I can't speak for typical ways of doing things with subversion... I only
converted my PVCS Version Manager Database to Subversion 3 months ago
(when 1.1.0 rc1 became available, because I needed the fsfs backend to
make my IT department happy). I used the method described above for my
testing repository where I have lots of common tests, but different
target configurations and gold files. I don't use the above method for
my source repository, because my sw developers have to checkout all the
projects and are required to do a "BuildAll" (which compiles all the
projects, and must contain 0 errors and 0 warnings) before commiting any
source code changes (to ensure changes to shared/common files/libs do
not break ANY project). So they have to checkout the entire source
>Thanks again for the tips.
You're Welcome... I received a lot of help from this list when getting
my systems setup, glad I can give back.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 19 21:05:29 2004