using metadata and relationships to control cm checkouts

Hi Craig,

  First we need to understand what you mean by "checkout".  There are two uses common in the CM world.  The first, and perhaps more logical, means to reserve a file (i.e. for editing), just as you would reserve a library book for reading.  Nobody else can make changes to the file (typically in the branch or release that it's checked out), until you check the file back in.  The second, and possibly (regrettably) more common use, is to retrieve a file from the library, with no real record of the retrieval typically kept (except in very secure environments). 
If you mean the first of these, Bob is correct in saying a hook, or script, is typically required.  Not all CM tools allow you to create such a hook on checkout however.  Not all tools allow you to "checkout" a file for editing.  You would also need a hook when the checkin operation occurs.  However, a few tools, such as CM+ (Neuma Technology) will automatically check in all files related to a given software update (a.k.a. a change).  You check in the change, and all files involved in the change are checked in.
A few points need to be noted. 

1.  If someone has one of these files checked out, it may not be possible to enforce your checkout strategy, and you may need to deny the checkout of "A" if "B" or "C" are already checked out. 

2.  You do not want to code these specific relationships in your scripts.  This removes CM data from the "library" and puts it into the scripts.  Instead, this should be done through an attribute which can be attached to a file which indicates that B and C depend on A at checkout time.   This attribute itself may need revision control (e.g.  no dependency in releases 1 and 2, but then in 3 to 5 the dependency exists, until removed again in release 6).   So depending on which release you're making a change to, the data in the repository should identify the dependency correctly.  The script for your hook should generically provide this capability based on the attribute value.

3.  The question as to why a checkout of B and C should be forced will arise.  Yes it prevents others from changing them, but no it doesn't force the developer to change them.  So your checkin rule may need to be more complex.

4. Some tools are easier than others when it comes to adding such a connection identification (between files).  In CM+, a single field would be added that could point to "connected" files.  It would be the responsibility of the owner of the file, or perhaps the CM manager, to fill in the connections.

In CM+ (the tool I use), such a checkout hook could be put in place as a single command that uses the attribute, as well as an if statement that verifies that the required files are not already checked out.  All files would automatically be checked in as part of the software update checkin.  Other tools also allow a collection of files into a software update.