Forum Discussion
We're not using GIT but we are using the TFS Version Control. In Visual Studio, the merge and compares are working but they take some gentle guidance at times.
The thing to remember is that those files you mentioned are formatted as XML files. What you can do is set up your version control to look at those extensions and treat them as XML. That should get you started at least. This is what I've done in the past with Mercurial.
- shankar_r8 years agoCommunity Hero
tristaanogreThanks for the input, I will try this option. If i got any better idea during this thing will share here.
- AlexKaras8 years agoChampion Level 3
Hi Shankar,
Any merging is an evil that must be avoided at all possible means because of high risk of merged items corruption. With this in mind, the best version control systems are those that lock changed files and do not allow concurrent changes (except of special cases set manually and explicitly).
Unfortunately, this is something that is hardly achievable nowadays... :(
I would recommend to set a process when all TestComplete project files except script unit ones are not changed concurrently. If any modification of any of these files is required, only one person must do it, commit changes to the repository and flag others that they can proceed.
As for the script unit files, they can be merged with much lower risk, but only in a case when changes are small and merges done often. This also must be set as an enforced development process. Otherwise you will get into merging nightmare when it is near to impossible to merge fine and quickly because of massive concurrent changes required to be merged.
P.S. Sounds not optimistic, but I never observed a real process that really worked when implemented different way.
- tristaanogre8 years agoEsteemed Contributor
Fully on board with AlexKaras on this. File locking is almost a must with many of the files. Things like tcScript and such not so much. NameMapping, however... hoo-boy....
What I've found is that the merging isn't as bad with these files if you're simply adding or modifying data. But, with NameMapping especially, if you delete large chunks of data or move objects around so that there are large changes of "delete from here, add to there", THAT'S where things get ugly.
We've managed to work through this by having our engineers do small, incremental changes. Basically, as soon as you add a new item to NameMapping and Alias it, check it in to source and then re-get the latest to get all current updates. Lather, rinse, repeat. This works fine for adding a new child object, modifying a property value, etc. For larger more "invasive" changes, we establish a file lock to prevent changes until the person is done making those changes.