Re: [4diac-dev] Retiring the old FORTE C++ Exporter

[Alois Zoitl <alois.zoitl@xxxxxx>]

On Thu, 2020-05-28 at 23:19 +0200, Jörg Walter wrote:
> On 28.05.20 21:57, Alois Zoitl wrote:
> > > -- but I did encounter issues with the new workflow
> > > using the merge tool, which is why I continue using the old exporter. My
> > > build environment does a 3-way-merge on top of that, which means that mos.
> >
> > I'm not sure if I understand that, because the new and old exporter use the same infrastructure and should use the same merge tool
>
> Strange... It automatically popped up the diff tool when using the new
> exporter, but not when using the old exporter. I thought it had
> something to do with the exporter, maybe it was a user error?

There is a checkbox if files should be silently overwritten or merged. I sofar always wanted to see the merges as I was doing bug fixes on the exporter to see
the differences. However now that you mention it I think hitting yes for overwriting also showed me the merge tool. I'll file a bug and look into it. Also yes
should be renamed into overwrite.
>
>
> > > I do appreciate the effort, however, and I think this is exactly the
> > > right direction, it just needs to be a 3-way-merge (old unedited file
> > > vs. new unedited file vs. old file with user-edits). Does the merging
> > > plugin support that?
> >
> > Would be hard if you don't have the old unedited file. Where should 4diac IDE get that from?
> > Furthermore the Eclipse merge tool which we are using currently only supports a two way merge. I don't know how to change this.
>
> Well then this discussion is hypothetical for the time being, but this
> is how I imagine it: during 4days of 4diac I proposed to automatically
> export all modified FB types into a well-defined path inside the project
> tree, behind the scenes, each time a type was modified. If such a path
> were available, export could easily manage all three versions: the
> current plain export, the previous plain export, and the user-modified
> file.
>
> That would also allow auto-merges, popping up the merge tool only when
> there are conflicts. Right now I emulate such behaviour using some CMake
> scripting and the diff/patch tools, which also works pretty well but is
> not part of the IDE experience.

Ah I still have to re-read all the ideas you had on the 4days of 4diac. with the new project layout we are stabilzing now this should be much better
implementable.

>
> Regards,