4

I have a remote Linux machine which I use as a development server for a web application. I cannot reproduce the environment locally, the files must execute on the remote server, but I want to edit them locally (in vim).

The files on this remote server are managed via Git. I typically only edit between 1-5 files at a time out of several hundred.

Suggested solutions, and why they don't work well:

sshfs: This solution seems awesome, but there are some bugs.

  • The local editor will hang while saving for a few seconds - there is no asyncronous saving in case of network delays.
  • If the network goes down while sshfs is active, it will actually brick that part of the filesystem until you do some hacky things to unmount it: http://sourceforge.net/p/fuse/mailman/message/26936619/
  • Overall quite slow since it constantly syncs data, rather than creating a local copy of that one file while editing

gvfs:

  • Operation is slow - takes a long time to open files, and the directory tree is not cached. Additionally, there is a bug (over 5 years old) which causes vim to trample over file permissions, meaning I have to update permissions via a remote ssh constantly

rsync:

  • Since this is a git repo, I may need to change branches frequently. There are times when the remote server may need to update me, and vice versa. Overall this adds a lot of complexity and would require manual syncing whenever I want to check a change on the remote server.

Use vim on remote machine via terminal:

  • There is a keystroke delay - this drives me insane.

gftp

  • The temporary file it creates has an arbitrary name - so you can't tell what tab is what
  • Requires a close of vim to update remote server (inane)

Surely there must be a better way? On Windows, I have used winSCP, which basically makes a temp copy of the file locally that you edit, and when you save it, it syncs the file in the background (so you can continue in the editor instantly after a save).

I found this question about emacs, but I don't want to use emacs :( how to ssh to remote server and use local emacs to edit files?

  • 2
    Maybe I'm missing something: why not just use git? Keep a local clone of the repos, make local commits, and do pushes to the remote machine whenever you want? – godlygeek Jan 9 '15 at 18:10
  • @godlygeek This would work, but would also be a bit slow. Have to admit I'm somewhat of a novice and often have to build things slowly, see what errors I get, and then fix those errors. I could be pushing upwards of 200x a day. – sricks Jan 9 '15 at 18:17
  • 1
    Practically speaking, using a git development branch and pushing/pulling to upload/download changes to the remote isn't very conceptually different from using rsync to do the same. If anything, it's less work for you: you don't have to worry about knowing exactly which files to move; git takes care of remembering that for you. So, this method should be no slower than rsync or scp, and less work than rsync or scp. There's no reason you couldn't push to a development branch 200 times in one day. – godlygeek Jan 9 '15 at 18:23
  • Git pushes do require an extra step - with sshfs or winSCP on Windows, it detects that you have saved a file from vim automatically, then updates the remote file for you. Rather than having to save in vim, alt tab, type command, and possibly enter a password without credential helper – sricks Jan 9 '15 at 18:29
  • 1
    Then ssh to the server and edit the files there. – psusi Jan 9 '15 at 23:15
3

One option missing from your list is Vim's netrw plugin (first mentioned by @godlygeek in the comments), which ships with Vim. You can :edit scp://hostname/path/to/file, or even specify such URL on launch: $ vim ftp://hostname/path/to/file. It supports multiple protocols, and handles the download / upload transparently (on each :write), while keeping the original filename, so filetype detection etc. still work.

  • This option did work for me, but there are a couple issues: loading is still slow (presumably due to the underlying interface), navigating to open multiple files requires lots of extra keypresses due to the protocol and inability to set a shorter local mountpoint – sricks Jan 15 '15 at 23:01
0

This may not be an acceptable solution for a production system, but you can run a sync service like BitTorrentSync (or any other) in conjunction to git. I do this between my laptop and desktop and it works great.

I can modify a file in a local git repo at home (and not commit or push). When I get to work the same modification is available. I can just finish and commit/push from there.

I have a ~/Git folder that is my main BitTorrentSync folder. In that folder I have multiple subdirectories for each repo. Just make sure you add the BitTorrentSync '.Sync' folder to '.gitignore'.

  • Question - this would be similar to the rsync scenario. But the issue is that I need to potentially sync in both directions. What will happen if I update a bunch of files locally, then on the remote server change branches? Will it get stuck on which copy is correct? Lastly, how is the latency? Ideally it should take effect within 2 seconds. My worry is that it does all files, rather than just the files I'm editing. – sricks Jan 15 '15 at 23:05
  • BitTorrent Sync works by constantly comparing the files and syncing only the changes. The sync happens both ways. I'm not sure what the current sync time is, but I think previously it used to be 10-15 minutes. But mind you I don't think BitSync works well for a LOT of small files (thousands of very small files). You can read mode details on their FAQ. – victorbrca Jan 20 '15 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.