Hi,
The best way was suggested in the first referenced thread :) : try to avoid merging by all means. There are a lot of cases when automated merging can work incorrectly and manual merging is a real hell.
So, the less merging, the more stable, controllable and predictable your test code and project structure are.
Thank you
I read your post on the mentioned thread, You said the following:
"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."
The process you are talking about should be managed then by a locking system, like TFS. Let's say i added the project to TFS: if one user takes the responsibility of adding/deleting tests, and others checked out the tests just to edit them... Can it be controlled this way in your opinion?
The problem that Stores and TestedApp parts of the project should be checked out by each user on each change! This is the thing i'm not arriving to understand.
Thank you again for your help..
