Remote changes?

#1

Is there any documentation about “remote changes”? In particular, how can I break the link so that cloning one board from another doesn’t automatically force merging on one when the other is changed?

It is not reasonable to force this type of relationship simply because two systems share a network. I have both development and test machines on my network. The contents of the test machines should only be updated in a controlled manner.

Also, a couple of suggestions: labeling the affected machines in the merge dialog would make it much easier to understand and the deploy button doesn’t become available after accepting a merge.

0 Likes

#2

Hi @Tim

just to clarify, are you referring to the Projects feature tracking changes in a remote git repository?

If you open up the Project Settings and go to the Settings tab, you’ll see the ‘Git remotes’ section. If you delete the remote it will no longer track the changes there.

The whole point of the git integration is to allow you to track changes between repositories. I’m not sure what ‘sharing a network’ has to do with it.

There are lots of workflows with git that allow you to manage separate test/development environments. For example, you can create a separate test and development branch on the repository. You can then push changes to the appropriate branch depending on what you want to do.

Node-RED doesn’t know about ‘machines’ - it is the git remote you are dealing with.

When you accept a merge the changes are already applied to the files in the runtime - so there’s nothing to deploy.

If I’ve misinterpreted your questions, please do explain a bit more how you are using Node-RED and what workflow you are using.

0 Likes

#3

Hi Nick. Thanks for getting back to me. My situation is very different from your description. The basics are:
21 Jun 13:35:42 - [info] Node-RED version: v0.18.7
21 Jun 13:35:42 - [info] Node.js version: v8.11.3
21 Jun 13:35:42 - [info] Linux 4.9.105-ti-r113 arm LE

This is an existing project that has been using node-red for years. I just updated linux and, in the process, updated node-red. I just rebuilt a test machine by using tar to copy the entire user directory (including the node-red installation) for the project from one BBB to another.

My admin screen doesn't match your description - see screenshot below
21%20AM

My main menu has an entry labeled "Settings" and there are only "View", "Keyboard", and "Palette" tabs.

My settings.js file has no information about a git repository. Again, this project was started long before this functionality was added to node-red.

The behavior that I'm seeing can best be shown by opening two browser windows - each holding the admin screen for a different machine. Place those two windows side-by-side so that the same flow is visible on each. Move a flow box by one square on the first window and click Deploy. The remote change detected dialog will pop up on the second window. If you accept the merge, the second window will update to match the first. If you click "ignore", the second system will continue to display the remote change detected dialog with each change deployed on first system. It is important to note that this is bidirectional.

"Node-RED doesn’t know about ‘machines’ - it is the git remote you are dealing with." - I don't know how that could be happening as there is no information that I can find to support such behavior.

"When you accept a merge the changes are already applied to the files in the runtime - so there’s nothing to deploy." - The blue change markers are still present on the affected nodes after the merge and need to be cleared.

0 Likes

#4

This is why my very first question was “just to clarify, are you referring to the Projects feature tracking changes in a remote git repository?”

Its clear you are not using the Projects feature we added in 0.18, so the rest of my reply is not relevant.

If you have two editors pointed at the same runtime instance then if you deploy changes from one editor, the other editor warns you about it and lets you merge those changes. This means if you have two users accessing the same runtime instance, they don’t accidentally overwrite each others changes.

But I struggle to relate that behaviour with your original question regarding multiple machines. What you have describe only happens when two editors access the same runtime instance. It has absolutely no link to other node-red instances running on other devices.

If you merge in changes, you are updating the flows in your editor to match what is on the runtime plus any changes you’d made in the meantime. If the net result is there are no changes compared to what is on the runtime, then the deploy button won’t be active - but nor should there by blue change dots on any nodes. So what you describe could be a bug - I will investigate.

0 Likes

#5

The “remote changes” warning you are seeing can only be happening if both BBB devices are writing their flows to the same local storage (I believe). By any chance, is your userdir on a shared network drive?

Another possibility is that DNS (or other naming service) is redirecting both browsers to the same IP address. In which case, the system is working as designed ;*)

0 Likes

#6

Nick, thank you. Your answer made the problem much clearer and once we understood the problem, we eventually found a networking problem.

Tim

0 Likes

#7

I hate to reopen this, but it turns out that what we are seeing is probably not a network problem. We removed all BBB’s from the network except for dev1 and test1, made changes to dev1, deployed and all was well. We then created a deployable update (tar file with embedded shell script that we run during the install), and ran the update on test1.

The install fetches the update from our webserver and runs a shell script that does a systemctl stop on our task (which is nodered based). It untars the file and moves the directories into place and then does a systemctl start on our task. As soon as we connected to the admin screen it prompted us to review changes.

After checking the diff to determine what it was seeing we were able to identify that “local changes” column looks like it comes from .flows_xxx.json.backup and the “remote changes” is coming from flows_xxx.json. Is this correct? If so, what is the purpose of this check?

What can we do to keep this from happening? Should we remove the backup flows file before restarting the task?

0 Likes

#8

When you say ‘connected to the admin screen’ what exactly do you mean? Was it:

  1. you open a new tab in a browser and loaded the node-red editor afresh in that tab.
  2. switched to an existing instance of the node-red editor that was already open?

I can only explain what you are seeing if it is #2 in that list.

  1. both dev1 and test1 are running flow version A
  2. You have an editor open and connected to test1. It has flow version A loaded.
  3. you update dev1 to flow version B. In doing so Node-RED creates a backup of the previous flow file. So you have flows_xxx.json that contain B and you have flows_xxx.json.backup that contain A
  4. You stop Node-RED on test1 - the existing editor loses its connection
  5. I assume your tar file and deploy process is copying over the .node-red directory - so both files are copied over.
  6. Node-RED is restarted on test1. The existing editor session reconnects and is notified the runtime is now running flow version B, so it prompts you to do the merge. The diff is between flow A - what it had when the editor was loaded, ie ‘local changes’ - and flow B, what the runtime now has, ‘remote changes’.

The .backup file is never read by Node-RED - its purely there for the user to be able to manually recover their last set of flows if they deploy by mistake. Its utility is somewhat superseded by the Projects feature in 0.18.

0 Likes

#9

Nick, I think that scenario #2 is correct. Just to make sure that I understand, let me restate:

If I had closed the editor tab before the update and then started the editor when the update completed there would have been no “review changes” dialog shown. What we are seeing is simply because the editor has a cached copy of the flows_xxx.json file.

If that is correct, it looks like we can safely ignore this issue as our customers will not see the editor.

Please confirm my understanding,
Tim

0 Likes

#10

The editor has flow version A. It reconnected to the runtime and was notified the runtime was now running version B which triggers the merge notification. That is working as designed and is the intended behaviour.

0 Likes