Hello - We use Bitbucket and Git Bash for all of our source control needs. We just started a proof of concept with TestComplete for a desktop Java application and are trying to establish our best practices and processes to scale the project up to 30 developers. We are currently having issues predicting what will happen when pushing and merging versions of the Name Mapping file. First for our goal: we want more than one person to add to the NameMapping file. We are being careful to not work on the same parent objects. We are still however seeing conflicts with the "TypeInfo Item0" tags where the keys keep changing between developers (this is in the xml of the file itself). When we try to deal with merge conflicts, it overwrites some of the data that the previous person committed. This is resulting in a lot of rework and we're losing confidence in the ability to scale the tool due to the unpredictability of merging changes. Does anyone have suggestions on how to best maintain a single NameMapping file, handle conflicts, and a predictable way for all 30 of our QA developers to pull these changes daily to their local through Git Bash? The safest way seems to be downloading the NameMapping file from Bitbucket and using Merge With from within the tool. This is not however efficient and will eventually lead to mistakes.

Best practice is, always, to have a single person maintaining your NameMapping. However, if you're going to have multiple, don't let the merge happen on the commit, have the merge happen on the pull. 1) Make NameMapping changes 2) Pull latest 3) Reconcile 4) Commit 5) Push And, something else that has helped us, make small, incremental changes to the mapping. The bigger the mapping change, the more chances there are to end up with conflicts.

I understand your intent but please allow me to express my deepest recommendation of NOT allowing multiple people to make changes to the tcnm file. I recommend for you to work the way TestComplete would like you to work and not go against the grain. I hope in the future that Testcomplete will implement a different way of using Name Mapping, maybe even a database like other products do, but until then, life is too short to have multiple people make changes to the tcnm file. Cheers -Lino

What we did was allow everyone to do their own mapping but not check it in. Then every week or so, (we rotatethis amongst the team because it's a rotten rotten job lol) one person takes everyone's name mapping and merges them one at a time into an empty project and fixes all the conflicts. Then each person gets a copy of the merged mapping and tries their tests and if it works for everyone, it gets checked in.

Hi RileyMartinez, I'm a Community Hero too. :) Really really really you can see that all the experts in this thread have said *DON'T* use your usual file source control process on the name mapping file. We are just trying to save you the pain that we have all been through when we tried it some other way and totally trashed the name mapping and had to start over again from scratch. If you are going to continue this way anyway, just make sure you have backups of all the different versions of your name mapping for when you have to go back. Also, you don't have to be stranded with one person handling the name mapping file. Make sure everyone can do it and switch it off once a month or something.

That's exactly it. LinoTadros is really right and one person should do the mapping, but with our team we were willing to take the risk of each person doing their own mapping. We choose a mutually good day to give all the mappings to one person and they merge and resolve conflicts with the TC tool. That copy is passed back to the team and we run our tests with it and adjustments are made if necessary. The new copy that works for everyone is then checked in. Any of us are capable of doing it, so we avoid problems with vacations and such.

NameMapping File and Git Source Control

tristaanogre
Esteemed Contributor
6 years ago
Best practice is, always, to have a single person maintaining your NameMapping.

However, if you're going to have multiple, don't let the merge happen on the commit, have the merge happen on the pull.

1) Make NameMapping changes

2) Pull latest

3) Reconcile

4) Commit

5) Push

And, something else that has helped us, make small, incremental changes to the mapping. The bigger the mapping change, the more chances there are to end up with conflicts.
- Marsha_R
  Moderator
  6 years ago
  What we did was allow everyone to do their own mapping but not check it in. Then every week or so, (we rotatethis amongst the team because it's a rotten rotten job lol) one person takes everyone's name mapping and merges them one at a time into an empty project and fixes all the conflicts. Then each person gets a copy of the merged mapping and tries their tests and if it works for everyone, it gets checked in.
  - LinoTadros
    Community Hero
    6 years ago
    I understand your intent but please allow me to express my deepest recommendation of NOT allowing multiple people to make changes to the tcnm file.
    
    I recommend for you to work the way TestComplete would like you to work and not go against the grain.
    
    I hope in the future that Testcomplete will implement a different way of using Name Mapping, maybe even a database like other products do, but until then, life is too short to have multiple people make changes to the tcnm file.
    
    Cheers
    
    -Lino
- RileyMartinez
  Occasional Contributor
  6 years ago
  Hi tristaanogre ,
  
  We have attempted a similar git workflow, and of course, run into conflicts on the pull. Could you elaborate more on how you reconcile the conflicts you run into? We're afraid of the consequences that could result from attempting to manually resolve each file. These are the files where we run into conflicts:
  
  - .tcNM
  
  - .NMimg
  
  If there's no elegant way to handle this, we will most likely have a single curator handle all of our NameMapping, but that really hampers our productivity. If that person were to be out of the office, then everyone else is kind of left stranded.
  
  Our plan B is similar to what Marsha_Ris doing, where we would pass each other's unique NameMapping files to a single person. Have them merge in each file one-by-one using TestComplete's merging tool, then pass the updated "master" file back out to everyone.
  
  As your title says, you appear to be a real "Community Hero" in these forums, so we appreciate your advice.
  
  Thanks,
  
  Riley M.
  - Marsha_R
    Moderator
    6 years ago
    Hi RileyMartinez, I'm a Community Hero too. :)
    
    Really really really you can see that all the experts in this thread have said *DON'T* use your usual file source control process on the name mapping file. We are just trying to save you the pain that we have all been through when we tried it some other way and totally trashed the name mapping and had to start over again from scratch.
    
    If you are going to continue this way anyway, just make sure you have backups of all the different versions of your name mapping for when you have to go back.
    
    Also, you don't have to be stranded with one person handling the name mapping file. Make sure everyone can do it and switch it off once a month or something.
cunderw
Community Hero
6 years ago
What has worked for us is to use your approach of using Test Completes built-in merge tool, but we also heavily use branches for any of our work so it minimizes the chance of conflicts.
AlexKaras
Champion Level 3
6 years ago
Hi,

Basically, none of the files that compose TestComplete project should be (auto) merged except script unit ones. And even those must be merged with care.
- maxtester
  Contributor
  6 years ago
  We were facing the same problem. As a result we did not use the name mapping. We use the 'find method' instead what makes the mapping much easier and even more maintainable. We have different scripts where we maintain the paths to the objects.
  - Marsha_R
    Moderator
    6 years ago
    maxtester
    
    So, now, every time an object changes, you have to hope that someone tells you before your test breaks and you spend an afternoon trying to figure out why? And then you have to update your scripts? That may be a familiar way to do it, but it's still more efficient with the TC name mapping. Better to have to spend a little time managing one file when you know it's changed than have to troubleshoot random changes to objects.