Advice on SCC and multiple VI checkout

[#1]

We have multiple developers and are setting up source code control. We intend to serialize development by locking any VI that is checked out, thus avoiding merging. There is an option in the Configure Source Control dialog, "Include callers when checking out files."  When you check out a common subVI or typedef, potentially many calling VIs may require compiling and saving. So is it easier to check them all out right from the start?  The choice has implications and I'm trying to make sure I understand the whole picture before formalizing our work practices.

1. You choose to check out all the callers when you edit a subVI

   A. All other developers are locked out of all those calling VIs.

   B. What if another developer already has one of the callers checked out?

   C. The good news is, if the change affects anything else in the hierarchy, it is easily saved since everything is already checked out.

   D. To avoid checking out all those other things, you could close everything but the subVI you are editing. Inconvenient, but possible.

2. You choose not to check out the callers

   A. Does not bother other developers.

   B. After a change, calling VIs may need to be recompiled and saved (especially when editing typedefs).

       Tricky problem: you have to find all the changed VIs, check them out, and save every one.

Maybe I'm missing something obvious here. Advice appreciated!

[tst]

I don't have an answer for you, since we don't really have this situation, but in the options screen (I believe in the misc. page) you should have an option for not prompting for saving on automatic changes. This means that a recompile does not prompt the user to save the VI and that you can just decide on a point in time where someone will save the VIs (or even wait until building).

Since I don't use that option (or the LabVIEW SCC integration) I can't give any specifics.

[Elijah_K]

I have observed that many team-based environments choose to avoid locking files, even if they aren't checked out to the developer - those that do tend to select 'Tread Read-Only VIs as Locked,' and 'Do Not Save Automatic Changes,' so that anything that causes a recompile in the background does not require checking out and checking in and should help with C & D of your first question.  That being said, they do need to mass compile at some point.

Does this help?  Anyone else do something differently?

I know that Subversion, which I recently started using, uses a different paradigm that avoids the need to check out files for modificaiton all-together, but I could see this resulting in more merging in a team-based environment.