info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Keeping a 'common linkage sandbox' up to date with CVS
Date: Wed, 30 Oct 2002 09:59:46 -0500

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.
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. are kept,
then checks their modified code back into CVS.

If the programmer were modifying a .lib or .obj, the makefiles currently
used would compile it into that 'common linkage sandbox'. Also, while their
initial .exes 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.
----------------------

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' each
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 update?

I don't want to have a programmer be required to check the whole system out
and recompile all objects before testing their code each time, which is why
we need the 'common linkage sandbox'. The system has hundreds of files and
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). At
the moment, going through and fixing that is not feasible. Also, I'm trying
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.e. almost a system test
situation), those items are not out of date.

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. 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.

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

Thanks,
Blaine
----
Blaine DeLancey
DeLancey Systems, LLC
address@hidden 
Consulting System Architect
(803)788-5808


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .






reply via email to

[Prev in Thread] Current Thread [Next in Thread]