Re: Keeping a 'common linkage sandbox' up to date with CVS

[Paul Sander]

What you call a "common linkage sandbox" is what is usually called a
"baseline" in SCM circles.  There are lots of ways to manage them.

They can be built automatically on a fixed schedule, or they can be
built on demand.  They can be populated with "cvs update -d" or with
something more sophisticated (e.g. cvs update -d -r LABEL where the
label identifies some reviewed change set or source base).  There are
also other change set management mechanisms such as submit/assemble.

Baselines can be accessed by computing paths based on environment variable
settings or configuration files or by using a publish/subscribe mechanism
such as buildrefs.

--- Forwarded mail from address@hidden

I realize this is probably a pretty basic newbie-type question, but haven'=
t
seen anything concrete in the FAQs or Google or recent mailing list topics=
=2E
If there's a good reference, please feel free to redirect me there!

Here's the setup I'm looking at using, and was wondering if anybody has
insight:
----------------------
A programmer checks out the few files they're working on from the CVS
repository, makes changes and compiles against another 'sandbox' where the=

latest versions of all includes, libraries, object modules, etc=2E are kep=
t,
then checks their modified code back into CVS=2E

If the programmer were modifying a =2Elib or =2Eobj, the makefiles current=
ly
used would compile it into that 'common linkage sandbox'=2E Also, while th=
eir
initial =2Eexes would be compiled and played with in their local working
directory, the final compile for system-test-ready would go to the 'common=

linkage sandbox' as well=2E
----------------------

What's the best way to keep the 'common linkage sandbox' up to date?

Should I just have CVS run a 'cvs update' against the 'common sandbox' eac=
h
time a checkin is done? Which of the admin files would be the place to
patch something like this into? 'verifymsg'? 'commitinfo' seems to be for
checks prior to commit - is there one for post-commit I could use for this=
?
Should I just create a custom checkin script that includes the extra updat=
e?

I don't want to have a programmer be required to check the whole system ou=
t
and recompile all objects before testing their code each time, which is wh=
y
we need the 'common linkage sandbox'=2E The system has hundreds of files a=
nd
it is not easy to determine what subsets of files are needed to properly
compile each executable due to poor programming practices in the initial
development (yes, the programmer could work that out by inspection of the
module they're working on, but I'd like to minimize the need for that)=2E =
At
the moment, going through and fixing that is not feasible=2E Also, I'm try=
ing
to minimize the chance that when they do their unit test they are either a=
)
linking against out-of-date libraries, or b) if it needs to be run in
conjunction with another executable/object (i=2Ee=2E almost a system test
situation), those items are not out of date=2E

It seems this would be a common issue with large projects, so I'm figuring=

there is a proper manner that's commonly used to handle it=2E I saw some
mention of the 'common sandbox' on the various Google searches I did, but
no detailed descriptions of how to keep that up-to-date, etc=2E

If I'm blathering, please feel free to request some deblathering
clarification from me!

--- End of forwarded message from address@hidden