[cvsnt] Ampersand modules and tags

Wed Jun 4 19:24:19 BST 2003

Ian Epperson wrote:
> Background:  We have many includes that are developed independently of the
> actual clients' programs.  Currently, we copy the includes into the clients'
> module for use.  That way, we know the include wont change unless we re-copy
> the file.  Unfortunately, field changes to the include seldom get back into
> the include modules.  

I didn't have time to respond to this originally...

If I understand what you are saying, you have a number of client modules which 
depend on a common set of include files.  e.g.

     clientA
        \includes1

     clientB
        \includes1

     clientC
        \includes1
        \includes2

where the include[n] files are mostly readonly, but occasionally updated for a 
given client and the changes are not being brought back into the repository in a 
timely fashion.

As long as the changes to the include files are intended to be shared (and not 
intended to be site specific), there is no reason you cannot manage this with 
either ampersand modules or directed checkout right now.  You don't need 
"ampertags" at all.

The important thing to realize is that every subdirectory in a given sandbox can 
come from a complete different module (even from completely different 
repositories and different servers).  The Apache source code is organized like 
this: checking out the http2 module does not give you the apr and apr-util files 
by default, but in order to build with them, you check those two modules out 
independently inside the existing http2 sandbox.

When you checkout the include file for a given client, you could immediately 
branch those files so that any local changes you made would be stored in the 
repository but on a branch, not HEAD.  Then, at some point, you could merge 
those changes to HEAD then push the unified file back out to each branch.  The 
merged file would then be automatically updated on the client sandbox at the 
nexe update.

HTH

John