sublime-rsync-ssh icon indicating copy to clipboard operation
sublime-rsync-ssh copied to clipboard

Destination folders of similar name cause multiple uploads

Open christophthiele opened this issue 9 years ago • 3 comments

Hello, I've stumbled over a problem where the plugin will sync with multiple destinations though only one was selected. It should be reproducible with a config of this kind:

"remotes":
{
    "project":
    [
        {
            "enabled": 1,
            "excludes":
            [
            ],
            "options":
            [
            ],
            "remote_host": "127.0.0.1",
            "remote_path": "/srv/dev",
            "remote_port": 22,
            "remote_post_command": "",
            "remote_pre_command": "",
            "remote_user": ""
        },
        {
            "enabled": 1,
            "excludes":
            [
            ],
            "options":
            [
            ],
            "remote_host": "127.0.0.1",
            "remote_path": "/srv/dev_test",
            "remote_port": 22,
            "remote_post_command": "",
            "remote_pre_command": "",
            "remote_user": ""
        }
    ],
}

The problem is that syncing to /srv/dev will do that but also sync with /srv/dev_test which is not what I want. I've looked into it and the plugin uses string inclusion logic to do file system checks and tries to retrace the user choice also by passing strings instead of the actual choice.

I've forked and fixed it on my side by rewriting RsyncSSH. It's the version I'm using right now, so there are some changes by now:

  • the above setup works
  • can sync single file
  • can sync selection via side bar context menu (little strange caused by sublime limiting the menu based on the selected type)
  • not using sync_on_save so didn't touch it

Maybe this affects somebody else and my logic works for you to. My fork

christophthiele avatar Jul 27 '16 15:07 christophthiele

This is a bug and should be fixed.

I like some of the changes in your fork, but definitely not all - this plugin is not ment for pushing code to production, I would advocate for a proper release procedure with something like Ansible, or Puppet - or at the bare minimum a dedicated release script.

Single file sync is already supported and happens on save. It can be turned off if you don't roll that way.

Selecting specific files for sync places a huge burden on the user, who now have to remember which files need to be synced.

The philosophy of this plugin is to keep the remote side in complete sync with the local side.

The local directory should always be master - it is either fully synced, or not synced. Thats the Enable/Disable on each "remote".

davidolrik avatar Jul 27 '16 20:07 davidolrik

It makes a lot more sense to me now as my use case is different in nature. I'm using it to locally develop stuff that needs to be tested on a dev server while others are also working on it, thus constantly forcing my version is not supported by our process. Release/production is not an issue and handled differently, but for testing I rely on selective sync.

But the folder based match idea would work regardless of use philosophy.

Thanks for clarifying.

christophthiele avatar Jul 27 '16 22:07 christophthiele

Uh, a shared environment like that is almost like deploying straight to production - I feel your pain.

davidolrik avatar Jul 30 '16 11:07 davidolrik