[cvsnt] Ampersand modules and tags

Ian Epperson Ian at axiomdesign.com
Wed Jun 4 21:30:23 BST 2003


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


Thanks for the response.

> -----Original Message-----
> From: John Peacock [mailto:jpeacock at rowman.com] 
> 
> 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.

Yes, that's right.


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

We do use this occasionally, but not as policy.

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

But here's the crux:  Suppose I work on clientA, and use include1, then
"finish" clientA.  I delete my sandbox because I'm done.  Now, working on
clientB and C results in include1 being modified and changed - maybe even in
radical ways.  ClientA calls back, I recheck out the files... and it doesn't
compile because of modifications to include1.  Alternately, 3 or 4
developers working on the same program would need to ensure they have the
same version (revision?) of the includes.

Note that this is simplified for discussion, in use, we're talking about 15
to 20 includes per project.

I am less concerned about the branched "include" development than I am about
making sure the "include" is the same for everyone on a project, always.  I
assume that if someone needs to do a field change to an include, then the
first thing they should do is move to HEAD and verify that the bug they are
working on is fixed.  This also means that when this happens, if other code
changes are required to deal with the latest version of the include, then so
be it - it's already being addressed.

A solution might be to tag each include with the Client name, and make sure
everyone updates all the includes (ampersand modules) to the tag, and move
the tags only when appropriate.  That's still a chunk of manual work for any
new developer picking up a project - as they'd have to go to each ampersand
module and update to the tag.  This might be scriptable in DOS, but it may
have to be modified for each project.  Another Q:  If you update a module to
a tag that doesn't exist, do you get the HEAD or simply an error?  Could
this be done once by updating the parent to the appropriate tag (assuming
the tag doesn't exist on the parent)?

An "ampertag" might define a default tag for an ampersand module to mitigate
this.



Another issue that has come up from this:  In one of the environments we
program in (proprietary software for proprietary hardware - Creston's SIMPL
Windows:  www.crestron.com) The IDE (if you can call it that) only allows
all the includes to come from a @#$#% single folder.  I was kicking around
the idea of creating a server side script that would build the "include"
module on a per-Client basis.  Hence the question in my last e-mail:  Can I
use soft or hard links on the server to present the same version controlled
file in different modules?  The alternative would be to have ampersand
modules (as described above) and mitigate the hard-links on the client.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook