Productivity of shared folders in Vagrant

Leading a large and regularly replenished team of programmers, I was faced with the need to quickly deploy a development environment without dancing with a tambourine in the spirit of “strange, does this code work for me, and what version of such a library do you have?”

Once received a link from the customer to Vagrant with the question "why do we not use it now?", He began to learn this miracle.

After some time, prepared Vagrantfile, in a matter of minutes expanding a complex system of repositories, libraries, servers and deployers. And everything would be fine, but one small unpleasant detail - all this either terribly slowed down / buggy, or (when executed locally) did not provide direct access to repositories stored inside the vagrant.
')
Many will say, but why do you need this direct access if you can store copies of files on the host machine and deliver them to the guest machine automatically, while saving them in the IDE.

That's right, but there is a nuance - the team needs the ability to switch branches on git repositories on the server, watch the result in the browser and edit the branch code in the IDE without departing from the cash register.

Many will say, but what's the problem, there is ssh and console git, and even show a maniac who drives in commands from the console git client from the keyboard faster than the client has time to execute them. One can agree with this statement, but having 10 repositories and several dozen branches per repository, I prefer to observe and manage all of this visually, through SourceTree, and have almost any team managing this large object, within the reach of three clicks.

Tried.

1. Shared Folders - the speed of script development was 10 times less than when executed with guest folders
2. Sshfs
   
   • permanent re-indexing in phpStorm
   • drop all files from git index when switching branches, with the need to constantly do reset --hard
   • inability of IDE and git clients to notice changes in files
3. NFS and NFS Reverse - stupidly refused to work on OSX without dancing with a tambourine (according to reviews on the Internet, they also do not solve the problem fundamentally)

A few days (weeks?) Spent on the study of this issue, it turned out that in my aspirations I was far from alone, but nothing smarter than one-way synchronization through rsync, today the public really did not see.

The closest thing I could find was the unison utility, which performs two-way incremental synchronization, and the vagrant plugin written for it - github.com/mrdavidlaing/vagrant-unison

True, there was another problem. The utility itself, automatically synchronize folders can only in the mode of every second restart, which was not supported by the vagrant plugin. A plugin can provide automatic synchronization, not even in repeat, but in event-based mode, but only in one direction (host-> guest). Moreover, the plugin was written under the version of vagrant 1.1, and today, it did not even perform the functions that are officially stated in it.

A little later, it turned out, despite the fact that the plug-in was not updated by the author from April 26, 2013, 7 months ago, another programmer attempted to bring the plug-in to life. The results of his work can be seen at: github.com/edtoon/vagrant-unison

Even its plugin, on the last vagrant (1.7.x) refuses to be installed. Having improved his code I managed to achieve

1. compatibility with 1.7.x;
2. support repeat mode;
3. the ability to resolve a unison database conflict after “vagrant destroy; vagrant up "command sync-cleanup.

Result I present to your attention at: github.com/dmatora/vagrant-unison
Ready plugin: www.dropbox.com/s/1yu1s7pr3qlr8ag/vagrant-unison-0.0.15.gem - for installation via

vagrant plugin install vagrant-unison-0.0.15.gem 

I have been using it for several days and still tweaking myself to make sure that I don’t dream about the lack of brakes and glitches.
However, according to rumors, for comfortable work, you need a 4 core processor (and SSD + Parallels is desirable)

PS In connection with the appeared comments, I attach an illustration from the article.
Vagrant - NFS shared folders for Mac / Linux hosts, Samba shares for Windows


PS Despite the fact that my fork has attracted attention (mostly burzhunet) and still lives its own life, I have to declare that at the moment I still use nfs_guest. I tried to use it before unison, but on my OSX it quietly refused to work until I found out that in order for nfs to work on OSX you must have a localhost entry in / etc / hosts. Unfortunately, nfs does not inform applications about events in the file system, but against the background of problems with synchronization and CPU load, this is tolerable. Unbearable blinking SourceTree, as it turned out, can be disabled in the settings (Refresh automaticly when files change)