I’m aware that it was an issue in osxfs, but it appears to have
been resolved, because events are being fired as expected from what
I can see.
With todays release of docker-sync 0.4.0 we probably have a promising final solution.
Since the new :cached mode wont be to effective ( see https://github.com/EugenMayer/docker-sync/wiki/4.-Performance ) we will need a external solution anyway - :cached is still 50 times slower then native.
The biggest concerns using docker-sync were host-dependencies ( @cweagans ) and that has been removed - there are no host dependencies any longer - just a gem on your system ruby. No brew, unison or unox.
In addition to that, no filewatchers are used anymore, so no crazy CPU usage. OSXFS is used in a away that the OSX->sync-container sync is done using the low level implementation of OSXFS, but the mount into your app container is done using a live-copy - that gives you native performance while having a 2-way sync without hazzles.
Just try it yourself and check the performance table https://github.com/EugenMayer/docker-sync/wiki/4.-Performance
Have a try, would be happy to have some feedback on this.
My solution:
I’ve just spent the past three days revisiting potential OSXFS workarounds. A slew of those workarounds were based on the concept of the container owning the code I was working on.
My concept worked like this:
- Have my repository in my host.
- My repository contained a directory “docroot” with ~17,000 files.
- I would spin up a container with a named volume.
- Spin up a Samba container to expose the named volume over the network.
- In the host I would mount the Samba share over my docroot directory.
- I would then be able to
git checkout -- docroot
to make git force my code into the named volume (and in turn the container) over the Samba share container.
This all worked, however my git commands were insanely slow (git status normally takes ~0.1 seconds would take ~12 seconds). This ultimately made me abandon the concept (I tried smb/nfs/etc).