OK i checked them, but what i want to know is what's the best way between the provided solutions? Is there any preferred one?
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.. :smileyembarrassed:
Thank you again for your help..
Hi,
> The problem that Stores and TestedApp parts of the project should be checked out by each user on each change!
Yes, correct.
This can be handled by the locking version control system (like Visual Source Safe). In this case only one user at a time will be allowed to check-out the file. And it should be a requirement to check-in the changed file the sooner the changes were done the better.
In case of non-locking version control systems (git, svn, cvs, ...) it should be test developers' responsibility to establish and follow the process like this:
-- Update sources often;
-- Update sources right before the change to some project configuration file (Stores, Script, .mds file, ...) is going to be done;
-- Implement required changes as quickly as possible (add test item, add/change project variable, add script unit, ...);
-- Save changes to the project;
-- Commit changes to the version control system to make them available for all other colleagues (in case of git it is a good idea to push changes to the central repository);
-- Continue with changes to the content of script units or keyword test file that this given user is responsible for.
Yes, this requires careful consideration and ahead actions planning, but this is the only real way to keep test project in a stable state with the minimal risk of losing changes made by whole team.
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..
