We have a shared, complex .hip file that is accessed by various devs from different offices. Naturally we run into a lot of issues with concurrent modifications, which we've attempted to organize through the creation of a large network of hierarchical HDAs. Ideally this would help us isolate changes to the section of the HDA network that we want to be editing. In theory, this is a great solution. In practice, it adds a lot of friction to the daily workflow:

• Editing a low-level HDA forces you to unlock all the parent HDAs above it, causing you to quickly lose track of which HDAs you had unlocked to access the nested nodes, and which you unlocked to apply real edits
  
• Creating new HDAs to encapsulate new complex areas is tedious and so developers avoid it
  
• Modifications to the shared hip file (newly installed HDAs, mainly) cause merge conflicts
  
• Since these are $HIP-relative HDAs, we have to install the nested children into any other .hip files that want to use the master node, which is tedious
  

I’m mainly concerned with the first point. I’ve tried a number of solutions – shelf tools to automatically unlock the full nested hierarchy, lists of editable nodes on the HDA type properties, using scripts to scan the unlocked nodes for substantive changes, ASCII saving. Nothing I can put together manages to solve all the sticky points.

Has anyone managed to address a similar problem? I feel as though I am missing a basic solution.