I’ve always thought along the lines Otto suggests, that eventually, given some way of formatting the diff, there would also be some visual tool in the ecosystem that would help visualize that diff and could be used specifically in the context of reviewing/merging changes.
Lots of good discussion on this thread, thanks all! Kevin > On Feb 25, 2020, at 15:44, Otto Fowler <ottobackwa...@gmail.com> wrote: > > -or- when diffing, some other representation could be presented other than > straight xml. > > The diff ( if run / visualized in nifi ) needn’t be byte for byte, it can be > logical can’t it? > > On February 25, 2020 at 14:58:24, Eric Secules (esecu...@gmail.com > <mailto:esecu...@gmail.com>) wrote: > >> Hi Ken, >> >> I feel like there are also issues in trying to build a pull-request-like >> workflow, in that most NiFi design is done visually on the canvas but there >> isn't a good way, that I know of, to represent differences between versions >> in a visual way. Even if you enabled pull request-like functionality, I >> don't know that I would expect users to approve changes by examining diffs >> in the XML files. >> >> I agree, doing PR can be improved by starting up a nifi instance and >> registry on top of the feature branch, so you can view the changes in a safe >> environment before approving. But this doesn't solve the issue of merging >> diverged versions. For that we'd need a visual representation of a diff. >> Maybe entering a 3 way diff mode with side-by-side canvases and no active >> processors where the differences are highlighted. Doing merge resolution at >> the XML level is a non-starter for me. >> >> I've tried out restarting the registry which works for receiving new >> changes. I have also had some trouble with loosing previous version history >> when restarting a registry, but the main issue would still be merging >> diverged branches. Maybe it would help to have some checkout mechanism and >> return to the days of centralized version control if merging is too >> difficult to implement. >> >> -Eric >> >> On Tue, Feb 25, 2020 at 9:36 AM Ken Swanson <kswan...@1904labs.com >> <mailto:kswan...@1904labs.com>> wrote: >> I have a lot of interest in this too, as my team has run into these issues >> as well. >> >> I feel like there are also issues in trying to build a pull-request-like >> workflow, in that most NiFi design is done visually on the canvas but there >> isn't a good way, that I know of, to represent differences between versions >> in a visual way. Even if you enabled pull request-like functionality, I >> don't know that I would expect users to approve changes by examining diffs >> in the XML files. >> >> However, I did have one thing to add that I hope might help: >> On Tue, Feb 25, 2020 at 12:32 AM Eric Secules <esecu...@gmail.com >> <mailto:esecu...@gmail.com>> wrote: >> I've also tried backing up my local registry to a separate branch in git and >> manually merging it with the branch that central-reg backs up to, but these >> git branches are glorified backups and the registry doesn't seem to be built >> to pull updates from them. On top of that doing a code review on the >> generated JSON describing a process group is difficult and I ran into >> several merge conflicts testing out a very simple merge where the target >> branch diverged slightly from the feature branch. >> >> From what I've seen, the registry will use any updates that are in the repo >> when it starts up. So you should be able to do something like this: >> Make the registry pull (or clone) from the backup as part of its startup >> process >> Restart the registry when a merge to master is made. AFAIK this should not >> affect any NiFi instances that are connected to the registry; they should >> continue to work once the registry comes back up >> It's a bit clunky but I think it works. >> >> -Ken
