Merging Two Projects into one

A little more history.  When we had a common SVN base early last month, it was quite painful to get there. At the time, we were not aware of the Name Mapping merge, but that is only within the same project suite anyway.



SmartBear has basically responded through a Support Ticket response that we do not support project suite merge.  It has to be done manually, but they provide no process sugestion of how to go about the merge, or even which files need to be merged.  The script files themselves are the easy part; when I asked about prject suite, project, NameMapping, Objects, and Stores, the response from Support was "You cannot merge these files directly - neither from TestComplete, nor using an external tool. These are the files that correspond to the Project and Project Suite nodes in the Project Explorer. They store the information about the project elements, Test Items, project and project suite settings - nothing from this list can be merged".



It seems to me that using ANY source control application presents these same issues, for scripts (supported very well) have associated data files (mentioned above) that are NOT supported well.  So if test developer A and B start with the same project base, A records new script X and B reconds new script Y, don't they have the same issue at the end of the day?  That is, the scripts are OK, but issues and conflicts occur in the associated data files that still must be manually resolved.



How do other companies and their users develop in a common environment and still manage to use a source control system?



 

Hello Everyone!





I just want to give some details regarding the question that was sent to Harlan - I believe, this information may be useful for other TestComplete users who struggles with the same issue:

Thanks for a detailed description of the question. It is actually an important question, and we realize this. That's why we created the "Teamwork" help topic to tell about some standard approaches: http://support.smartbear.com/viewarticle/27356/ In a nutshell, all the rules come to just a couple of ideas: - do not merge anything that is not a script unit file; - for everything except for script unit files, disable multiple checkout in your SCC system. This means that you need to organize your tests structure in a way, so that the situation when several people need exclusive access to the same project item occurs as rare as possible. Please read more details in the mentioned Help system section - there are multiple useful topics there. As a rule, the most problematic thing is the Name Mapping file - exclusive access to this file may be required too often. However, we don't have a universal solution here, unfortunately. Possible approaches include: - Having several projects with an isolated Name mapping file in each project. Every of the projects may be bound to testing a specific part of the tested application, sot that the Name Mapping schemes overlap only on the Process and main window level. - Separating the Name Mapping structure creation, and the test logic creation, so that one person creates the Name Mapping structure for a specific part of the tested application, then check in the changes, and continues creating the test logic, while another tester creates another part of the Name Mapping scheme. - Not using Name Mapping, and addressing objects by their non-mapped names, according to the Object Browser structure. There may be other approaches suitable for your specific situation.

Do you have any improvements planned for this area?  Also, as a general question, do you post upcoming features somewhere prior to their release?



We're new with this tool and looking at strategies that allow many people to work at once and allow common function libraries.



It would be VERY helpful if a project could #use a name mapping file from other projects.  Allow them to be in multiple files so that maintenance is easy.  Fix something in one place/project and use it in another.  This surely beats having to make the same change in 20 different projects because a reused definition is changed.  There is a merging process that you have for name mappings and I'd suggest that this gets called at the start of execution.. sort of a compile phase.  Allow the users to specify behavior if there are duplicate entries.