Git merging and conflict-resolving Ranorex Repositories

[uhmdown]

We are using Git for source control, and are approaching a scenario where we need to merge a repository that has branched.

I'm wondering, what's the best way to do this?

A couple of thoughts so far (please correct me if I'm wrong):
- The cs file can be added to the ignore list, because Ranorex autogenerates them anyway.
- Can't use Git to resolve repo conflicts, because resolving it in the xml file could be unreliable


It seems to me that the best way to resolve conflicts is manually through the Ranorex' repo editor, thereby ensuring that when doing the merge, the manually updated repository can simply replace the other, sidestepping potential conflicts.
That means pulling and merging all code modules, and then placing the repositories side by side and resolving conflicts in the repo editor until the code can be compiled and only needs to reference one of the repositories (the one that is "merged" and can completely replace the other when doing a git merge).


I've seen others mention a strategy that entails avoiding multiple people working on the same repository altogether, but that just seems wrong to me.

Does anybody have some other experiences with this?

[odklizec]

Hi,

Are you using latest 7.1 and GIT integrated with Ranorex Studio? Because in this version, it should be easier to merge conflicts in repositories. This is what "release notes" say about it...

Collaboration: The object repository can now get auto-merged in various conflicting situations after concurrent modifications (when version control integration with GIT or SVN is in use).

[krstcs]

You should NOT add *.cs files to the ignore list. Even though Ranorex will auto-generate the ones IT creates, it WON'T do that for ones YOU create, and in Git, it's all or nothing for ignore.

I have rarely had issues with merging branches, just make sure your working branch is up-to-date with the latest changes in origin and then merge. Make sure you are doing this locally though so you can fix anything before it is in the cloud.

I use Git for repo merges as well. If you try to merge and then have a conflict, only Git will know that. Ranorex won't know and then will throw errors when trying to open the repo file. This is the same for any other *.rx* file, because they are all XML files.

You just have to be careful about it and get a good understanding of the structure, and then you can do it without causing any more issues. It just takes a bit to get the hang of how Git and Ranorex work together.

Fortunately, Ranorex is working on making merging easier with each new release, so it is getting better.

[uhmdown]

Thx for your replies.

We are using 7.1 with integrated Git.

We are are only ignoring the cs files associated with repo files.
We placed all repositories in a dedicated folder, so we just ignore the cs files in that specific folder.
All other cs files, including those created by recording modules, are tracked by Git.

krstcs, is there more than one person working on your repository in parallel (which is what we're doing)?
And you resolve repo conflicts directly (and only) in the repo xml file?

[krstcs]

I'm the only one. And in my current position I'm still working on standing up the automation solution.

However, in my previous position we had 3 different version stacks for our AUT in the test environment, so I had long running branches for each version stack. This meant that, practically, there were 3 branches being maintained simultaneously (on top of any feature branches) and I would need to merge up and down as features moved through the pipeline. So I actually had to worry about what changes I was making would do to other changes I was making. So there were times when I had to fix the repo or test suites (usually not modules though as I keep those REALLY REALLY SMALL) due to merge conflicts, even though I was the only one actually working on the projects.

So, it's not always about the number of people (although the more there are, the more important it is to follow well established rules), but can be about the complexity of the project/environment as well.


EDIT TO ADD: I would still keep the repo in Git so Ranorex doesn't have to recreate it each time. I've never found it to be better to do it that way than to just keep it in Git. In addition, this means that you can always open the project in Visual Studio and not have problems. Visual Studio will NOT recreate the repo CS files, but if they're in Git, you don't have to worry about it.

[uhmdown]

Thank you; these are good points.

[jbeeson]

When you guys are talking about "integrated git," do you mean TortoiseGit? Or is there another implementation now? I recently had to merge repos and still got all kinds of conflicts even though we didn't touch the same items.

I'm running the latest 7.1.

[krstcs]

I think that is what he meant. I actually prefer to use POSH-GIT since the PowerShell integration is pretty sweet, so I don't have TortoiseGit installed. I've just gotten used to doing everything through the command-line, which means it is the same in every environment, where as each of the GUIs do things differently.

[Fergal]

...make sure your working branch is up-to-date with the latest changes in origin.... Make sure you are doing this locally...

(Sorry for bringing up an old topic) Could you please outline the steps for doing that? Are you doing a "Pull" from the origin or something else. I am using Ranorex 8 and Tortoise Git.

Many thanks.

[krstcs]

Depending on what changes have been made upstream, you may need to do a merge from master. I've had 2-3 branches for different features and when I merged one back to master when I was finished, I would need to merge master back down to the other branches.

Pull and Fetch only work off the current working branch, so they would only get changes to that branch from the server, so if your current branch has upstream changes, then you would Fetch and Pull. But if you are working on a feature branch off of master (or another long-running branch) then you would still need to merge the parent branch into your feature branch.

[Fergal]

Thanks for your helpful reply and explanation krstcs.

[DavidHay]

We are starting to build up our repositories. We now have two people working on the same repository at the same time. Until recently the merges have been easily managed because the branches do not stay around for long. Small features and small merges. Now the repositories are bigger, and we now have some feature branches that have been around for a while, the merges have become more challenging. If I take care merging the rxrep file do I need to worry about the cs file, or will that be auto-generated again when loaded into Ranorex?

[DavidHay]

From my latest experiment, merging the rxrep file manually worked. I am going to start using 'git merge master --no-commit --no-ff' so that when I update my branch with master, I get to make all the decisions on what change to select. A bit more work but I think I will have more confidence in merges.

From the Git documentation:

With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing.

[krstcs]

I highly recommend that you keep all *.cs files in Git and merge them along with the *.rx* files.

Don't depend on Ranorex rebuilding them every time. And, if you need to use an editor other than Ranorex Studio, you will have problems because no other editor will auto-generate the files.

[DavidHay]

Yes, I still have the *.cs files in Git. I am just manually merging the rxrep files and leaving the *.cs to normal merging.