I'm struggling with GIT code maintenance with Test Complete project.
We have a customized data-driven framework which created like One project in a Project Suite. All the Business components will be inside of the Project and etc. And we are having GIT repo which used by us to commit our Project. In the same branch 2 resources are working with same Project. When committing script files we not having any problems. But when it is come to Project files like .mds, .pjs, .tc** we are facing lot of issues since git not able to merge these files.
So, If my above scenario bit of confusing then I just need to know how you guys managing the Project files in GIT repo.
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.
I just need to know how you guys managing the Project files in GIT repo.
Because I'm the only one that ever pushes to my repo!
Sorry. I know that doesn't help. But as I'm the only one committing to it, I've never had to bother with a merge.
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.
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.
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. 😄 🙂
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.