FAQs
xeno is fairly stable, and I use it in my daily work. Most of the heavy lifting is done by Git and SSH, and consequently the room for error is significantly reduced vs. rolling one's own sync implementation. There is also regular Travis CI testing which does end-to-end tests of the synchronization mechanism. Check out the issue tracker for a list of any current issues.
Because the synchronization is effectively stateless, xeno is also far more robust to connection dropouts than SSHFS, meaning it is far less likely to cause you to lose any unsynchronized work, and it will keep trying to reconnect indefinitely without breaking a sweat. Of course, as with anything that touches your filesystem, you should make backups regularly!
Yes! The best way to do this is to set up SSH connection multiplexing. Instead of trying to document that here, I'll point you to this awesome article by Rackspace. This will significantly improve the performance of Git as well.
In principle, I'd be paranoid about anything wrapping my SSH command. The only reason I trust this one is that I wrote it, and even still, I'm paranoid. The source for the wrapper is available available in the xeno source code (grep for xeno_ssh and xeno_ssh_monitor), so you can see exactly what it does. The basic idea is that it tees off SSH's output into a FIFO that is restricted to the user, and monitors the FIFO for xeno initialization messages in the SSH output. That's it. Your SSH session never hits disk, it is not available to other users, and xeno knows nothing about the transport/encryption/authentication. All xeno sees is what you see on your console. The alternative would be to reverse-forward a port on the remote end and start a daemon locally like rmate does, but this is even more insecure since the forwarded port is not restricted to the remote user. In general though, you are not required to use the xeno ssh wrapper to use xeno, it is only a convenience so you don't have to explicitly type user@host:/path specifications to xeno edit and don't have to drop out of your SSH session. But I think it is a worthwhile convenience, and I would strongly encourage you to review the code before using it. If you can think of a better way to do this without forwarding a port and starting a daemon to listen, I'm all ears.
No, you can exit your SSH session once the editing session has begun. xeno is also fine for working offline - it will just sync its changes at the next available opportunity.
Yes. Using passwords is a terrible practice for SSH, and will cause you to have arthritis even earlier.
No. xeno runs a daemon locally to keep changes in sync, and uses a Git hook on the remote end to do its bidding.
No. xeno will copy itself to a private location on the remote end (~/.xeno-remote) in order to do its bidding. However, if you want to use xeno for in-SSH-session launches, you will need to install it on the remote end.
Yes! xeno uses Git's GIT_DIR and GIT_WORK_TREE support to create a separate Git repository outside of the remote path, so it will not interfere with any existing Git repository, and your existing repository will still track the changes as they come in via xeno's syncing mechanism. xeno will however use the .gitignore file found in any remote editing path, and will not bring over those files to your local copy for editing, but beyond that there is not interface with any existing source control on the remote files.
Yes. For more information, see the FAQ above and the documentation of the edit command.
Not at the moment, and it is probably unlikely given the lack of really viable Git and SSH support and the utter lack of a decent shell. It might work with something like Cygwin, though I have not tried (I'd be curious if someone gives it a shot).