Forum Discussion
tristaanogreThanks for the input, I will try this option. If i got any better idea during this thing will share here.
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.
- Colin_McCrae8 years agoCommunity Hero
This all sounds truly horrible and I'm more glad than ever I don't have to deal with merges!
- shankar_r8 years agoCommunity Hero
Hrm...Looks like i will get into a very good bad times when doing merge. But nevertheless I having some options in my plate now, will try to do those if i got any luck then fine otherwise as i say VERY GOOD BAD times. :robotmad:
- AlexKaras8 years agoChampion Level 3
Absolutely in line with Robert.
P.S. Colin_McCrae: You are a lucky one... Really... But keep working hard, so that management never come to the idea to hire someone else to help you with tests automation. :D :)
Related Content
Recent Discussions
- 3 days agovladd1