A couple of strategies for managing NameMapping came up at the recent connect conference.
1) Have one person designated as the "Master of all NameMapping". Anything that needs to be mapped, they map. They do the mapping ahead of time before automation against the components is started. Then all automation developers download the latest mapping file before working on that piece of the application under test.
2) Have one person in charge of "merging" NameMapping. No NameMapping is actually checked in to your SCM from the individuals. Instead, they do their mapping and then send their NameMapping.tcNM files to another party. That person then has a special project in TestComplete whose sole purpose is to use the built in TestComplete "Merge" feature to merge those individual namemapping files into the central one, resolve all conflicts, and then check in to SCM. Then, once the merging is complete (sounds like a bad sci-fi trope...), the individuals download the latest NameMapping. I believe Marsha_R uses this method.
As for the other files within Regions, Files, Objects, XML, the way we handle that here is that we a) don't put stores files in different directories. We just store them in the default project folder structure and use a naming convention to describe what the files are. And b), no two people are working on the same file at the same time. This is a bit harder to control "automatically", but generally it's a matter of making sure that if I am working with XMLFile1, no one else is at the same time. That way there is no conflict and we don't have to worry about it. This might not work for you, depending upon how you structure things.
I like the idea of a "Master of Name Mapping" role. I am not sure that it would work well in our particular circumstance (because that role would probably fall upon me and I would become the bottleneck :-) ), but it makes a lot of sense in general. As an alternative, I do the reviews of all the team members' work. At that time I go through all the name mapping changes with a fined-toothed comb. That seems to take up less time and allows for more concurrency of development by the team.
The biggest problems we have are with the Regions.tcRegions, Objects.tcObjects, and Files.tcFiles directory files rather than the stores files themselves. Everybody is hitting the directory files (not sure what else to call them) all of the time. We use folders within the directory files to organize our work. It seems to have the added benefit of partitioning off groups of file pointers within the XML such that we do not modify the same sub-elements at the same time within the XML. This helps to avoid a lot of conflicts. But when we do have conflicts, the traditional resolution strategies ("use theirs", "use mine", "use neither", "mine first, then theirs", "theirs first, then mine"...) don't seem to work very well. I think it may have to do with the way TestComplete generates UID's in the XML. My theory is that TestComplete does not do a good job of keeping the UID around when an element position changes within the document. For some reason, new UID's are assigned and then the mess begins. For example, in a "keep mine" resolution, I may be discarding a newly assigned UID and keeping the old UID and basically making my element an orphan within the system.
Thanks for the thoughts.
Yeah, the flat XML structure of the files, including how NameMapping is constructed, is a general problem with source control. What I usually do, if there's a conflict, is manually merge them. That's really the only way to control some of it.
Yes, we use #2. It does sound like a bad sci-fi trope, but Name Mapping acts like an alien sometimes, so I think it's appropriate. :D
