NameMapping File and Git Source Control

[rsvonddy]

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.

[Marsha_R]

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.  

[RileyMartinez]

Hi @Marsha_R,

Yes sorry, I should have mentioned you are Community Hero of equal stature haha. Giving what you're saying about this, would you recommend Option B?

Also, Option B is how I understood the explanation of how your team handles multiple contributors. Let me know if I got the details wrong there.

Thanks!

[Marsha_R]

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.

[RileyMartinez]

@Marsha_R,

Awesome—thank you for the clarification! How often would you say you run into issues when passing the merged NameMapping file back for testing?

[tristaanogre]

For us, we're using TF Version control and not Git.  Small, incremental merges within that tool have been doing well for us.  We haven't had any major problems.  We don't use the NameMapping imaging.  Of course, lately, we've only really had two people doing the work against the NameMapping file so it's really rather easy to track merges and such.

[Marsha_R]

@RileyMartinez Maybe one or two conflicts a month?  We're usually working in separate areas of the application so we don't bounce off each other much.  They're really pretty easy to fix.  It's not as complicated as resolving code conflicts.  

[tphillips]

Sorry to potentially necro-bump but we are facing the same issue here, and IMO having only one person maintain name mapping is just a work-around to the real problem: TestComplete's approach of using one single monolithic file for the entire name mapping just doesn't scale well. It should be broken up into somewhat of a folder structure or something.

Relying on one person to maintain the name mapping is just inefficient.

[LinoTadros]

I don't disagree

[AlexKaras]

Hi,

> It should be broken up into somewhat of a folder structure

Actually, it you stick to this approach now and make an agreement within the team who is supposed to make a changes to this or that part of NameMapping (e.g. one person automates everything along the Order workflow path and another person automates everything along the Payment Accounting path) and you commit as soon as you make a change to NameMapping and verify that the change works for you, well in this case the risk of conflict is rather small.

Obviously, if someone works for 3-4 months within the whole application and then tries to commit, merge conflicts would be hardly resolvable. But I bet that the same situation will be for the source code as well. And even if we talk not about TestComplete but, say, Visual Studio.

[tristaanogre]

I've also found that the majority of the problematic conflicts are if you're deleting segments of the NameMapping or doing a large re-structuring (click, drag, replace, etc) of existing trees AT THE SAME TIME as others are adding segments to the NameMapping.  This creates all SORTS of conflicts.  Just having two people adding new objects in different, unrelated trees doesn't cause much problems at all.