Automatic conflict resolution seems broken/disabled

[BalzGuenat]

rtc2git/rtcFunctions.py

Line 248 in dc0736c

# self.retryacceptincludingnextchangesets(changeEntry, changeentries)

The above line was commented out at some point. Seems to me like that broke (or rather disabled) the automatic conflict resolution. Why was it commented out? How else is the resolution supposed to work?

[WtfJoke]

We thought with the changes of the accept command it shouldnt occur anymore and therefore commented the code out.

So currently there is no automatic conflict resolution and should be rather done manually 😅

[BalzGuenat]

Hm, not sure if that is practical, unless I'm missing something...

I'm currently trying to migrate a ~3000 change set history and end up having to resolve conflicts every few minutes. To resolve each properly, I'd have to unaccept change sets, create a new branch at the merge base, manually accept and commit all changes up to the merge, start the merge in git, accept the merge change set, commit the merge, then finally let rtc2git continue. But still not fully automatically, because it now complains because it tries to accept change sets that are already accepted.

Is this the current intended way to resolve conflicts?

What I'm doing currently is

• Instead of keeping tabs locally, I ask the server, which change sets are actually accepted, so I don't try to accept change sets already in the workspace.
• Simply ignore conflicts in the workspace and treat them like successful accepts. (I check the exit code.) The merge change set will usually be accepted soon after anyway. The resulting Git history might not be as clean as could be.

[gpflaum]

@BalzGuenat Are you using a history file? You are very likely to have conflicts if you don't use a history file.

[BalzGuenat]

Yes I am.

…

On Mon, May 27, 2019 at 9:04 PM Greg Pflaum ***@***.***> wrote: @BalzGuenat <https://github.com/BalzGuenat> Are you using a history file <https://github.com/rtcTo/rtc2git/wiki/Getting-your-History-Files>? You are very likely to have conflicts if you don't use a history file. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#155?email_source=notifications&email_token=ABTIMJWZ22FTPD2X4OZ5DGLPXQWFHA5CNFSM4HN7Y6X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKL3FY#issuecomment-496287127>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABTIMJQE5MTCFO44AFZAAMTPXQWFHANCNFSM4HN7Y6XQ> .

[areebrtc]

I am also facing same issue as conflicts are more frequent in my case. Just after each 50-70 change sets conflict occurs and accept start to fail.

What strategy are you following @BalzGuenat to resolve your conflicts? Does enabling autoconflict resolution solves this problem ?

[WtfJoke]

I think when we commented the code out we decided to wait, until somebody is having the need of this conflict resolution.

I wont mind to uncomment this line.
Just when I looked at the code I remember, that I also didnt like how to revert the changesets (using discard), usually it led to problems. I probably would leave that block commented.

* Instead of keeping tabs locally

What do you mean by that?

[BalzGuenat]

@areebrtc My "strategy" is to just treat a change set that, when accepted, leads to conflicts, the same as any other change set. That is, I ignore conflicts and let them get resolved when eventually the change set with the merges gets accepted. This won't look perfect in the git history but it's good enough for me.

One problem I found when I activated the conflict resolution was that I had lots of issues (read: required manual intervention) with change sets trying to be accepted that were already accepted as part of conflict resolution. That's why I went with my current "dumb" strategy.