using metadata and relationships to control cm checkouts

Craig Neill's picture
Craig Neill asked on November 10, 2015 - 2:16pm | Replies (3).

How can we use metadata to control checkouts in a CM tool?
I.E. Is there a tool which will allow us to identify connections such that, Iif I check out object "A" the the tool will force the checkout of Items "B" and "C" as well.

3 Answers

Bob Aiello's picture
Bob Aiello replied on November 20, 2015 - 4:17pm.

which version control tool are you using? Normally, you would use scripts that are often called "hooks".
In many version control systems, hook execute based upon common events such as pre-check, commit etc.

Feel free to provide more details

Bob Aiello, Technical Editor CM Crossroads

Joe Farah's picture
Joe Farah replied on December 7, 2015 - 3:18pm.

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.

Craig Neill's picture

Bob and Joe..

Thank you so much for your informative answers.
This question is part of a research effort which I have been asked to undertake in support of a software integration (as opposed to software development) activity, in which numerous components are brought together to complete a larger application.  
We are looking at ways to impove efficiency and reduce the errors inherant in that kind of activity.
The hope is to use a CM tool to "contaierize" components and put them under CM control.

In that way , the components themselves would be well identified, documented and controlled.
In addition, if dependant or connected components could be identified within the CM system, we should be able to report and analyze the revsions and connections between them...

Also, when a particular component is drawn out of the archive for integration, it's companion or dependant items could be brought along as well without requiring additional research to identify them.

I hope that clarifies the question a bit.
Again, thanks again for your feedback.



CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.