[reynolds]

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers.

Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

[mitchellh]

I understand you use the rsync approach since its similar to how you actually deploy, which is completely understandable, but I just wanted to note that John and I struggled with the shared folder performance issue + Vagrant for months, and we did a LOT (months) of real world tests with various solutions (John at one point even integrated background automated rsync directly into Vagrant), we found that NFS is really the only satisfying solution (for us, at least).

NFS allows us to edit code locally on our host, and have it "instantly" be ready on the guest. After just half an hour of working, the various inodes are cached on the guest and file system access over NFS is mostly native-speed since it only needs to grab changed pieces.

The end result: We completely ripped out background rsync despite John working weeks on it, and we put in built-in support for NFS, which has been going strong since around July now and is happily at work at many places that use Vagrant :)

[garethr]

People might be interested in DoubleDown (http://blog.devstructure.com/introducing-doubledown) from the DevStructure guys. It uses rsync in a similar background manner and it's designed with this exact problem in mind.

[ciniglio]

Can you elaborate on that background process? Is that something built into rsync?

[reynolds]

It's actually something I've been working on that I want to put up on github. I hacked up a Python version of it as a proof-of-concept but rewrote it in C as an installable executable using autotools.

Basically I tell it which directory I want it to watch for changes and it does automatic syncing by piping rsync. I keep a local and remote signature of the files and their timestamps. When it first starts up, it pulls the server sig file and compares it to the local one. If there's a mismatch, the server is updated. From there it manages the signatures locally until they're different.

Writing the sig file to the remote server is done in the same rsync pass because it's stored in the local directory as a dotfile.

I realize rsync does its own checksums, but using my own crude signature files makes it so I don't have to keep calling rsync. I only call it when something changes.

I also have some stuff I'm working on that ties into auto-restarting servers when syncing finishes, rolling server deployments for no downtime, db migrations, etc.

[epoch7]

Sounds like some pretty cool stuff! I hope you post about it when you do decide to release it. :)