RE: 'singlecopy' oddities in 2.0.5

[Eric Sorenson]

On Mon, 5 May 2003, Wheeler, John wrote:

> Good example. It looks like there is an assumption that the source file
> will always exist, and a more specific file may overlay the more general
> copy. I was wrestling with this problem earlier and came up with a
> different solution. I propose an additional parameter for the copy
> directive that would work in conjunction with the single copy feature.
> This additional directive would be a CVS tag or label. 

Yes, as I mentioned, you'd have to specifically configure a copy:
directive for each file under management.  I'm only up to about 
fifteen files with a max of 5 or 6 'overlays' for each file at this
point and its repetitive but basically OK.  The differences between our
various $(role) are pretty easily abstracted at this point because this
cfengine rollout is going out in parallel with a sitewide distribution
upgrade. If I didn't have the luxury of ignoring legacy machines I could
see it getting ugly pretty quickly.  

> The initial design would be to simply have cfservd access CVS through
> a local copy of the client. This could be further integrated if
> desired to support the full capabilities of CVS. Some variables would
> need to be defined that indicate how cfservd would contact CVS, and
> then a few command strings would need to be defined. Some thinks get a
> bit tricky that I haven't put to much thought into like type=checksum.
> If the CVS repository is local as well then some of these may become
> easier. 

I'm not sure I understand the benefit of rolling this inside
cfengine -- my repository is a checked-out CVS tree and I manage
the version control of the files it contains as a meta-problem.
This keeps cfengine's job simple -- it knows what files to look for
and it's at my discretion which branch/version it will find.

What problems did you run into for which this type of approach 
didn't work?

-- 

    Eric Sorenson - EXPLOSIVE Networking - http://explosive.net