>The main hassle I found at NAB (I contracted there a few years back - tell Goran that I said g'day but I still can't come back at this time <g> ) is version control with classlibs containing different classes being worked on by more than one developer.

This bit about classes in a classlib is actually interesting. We already had a thread once about how many classes should there be in one, and that one was quite long and a bit religious.

At the opposite ends of the spectrum were the "one class, one classlib" and the "just put them all in one big vcx". The former has the simplest to handle in VSS, and didn't put unnecessary parts into a project, but then you got too many files in the project and had to somehow remember what was where. Good naming convention would be essential.

The other end obviously lost - one programmer checking out the big lib would either prevent the others from working on it, or create problems if two guys added different classes to the lib, as one would be lost and would have to be added manually.

The solutions to this that I saw were either on the most granular case (one per, good naming), or somewhere in between, with classes arranged into classlibs by theme. For instance, there were about 100 reporting classes, and these were grouped into about a dozen of classlibs by theme (sales reports, schedules, personnel reports etc), so when the time came to rework almost all of them, it could be done by several programmers at once, without stepping on each other's toes.