Discuss weather to add --delete to rsync by default

[EugenMayer]

rsync does not use --delete for now, but i worked with that already. I am yet not sure if we should add it to the defaults and make it possible to disable it ( there are some cases were you do not want this, i have such ) or keep the default as such.

Any suggestions?

[mickaelperrin]

I didn't give a try to the rsync version of docker_sync, but could you confirm that it has the same issues of docker-osx-dev and any rsync implementation, aka:

• without --deleted, files deleted on the host are not deleted in the container ?
• with --deleted, files created in the container are deleted after each sync ?

Or do you use some additionnals rsync options I missed or any other specific implementation ?

[EugenMayer]

without --deleted, files deleted on the host are not deleted in the container ?

this can be fixed

with --deleted, files created in the container are deleted after each sync ?

is in fact the reason i do not use it ---delete

In drupal, you create a new site in the container by creating a folder in /app/code/sites/
If you do that, and a sync happens, that thing will be deleted, since the host does not have this folder.

One of the reason of one way rsyncing

[mickaelperrin]

How do you intend to resolve the first issue ? I got the same issue while playing with docker-osx-dev and what I did was to parse the fsevents stream and forward delete events through ssh to the vm. I don't really trust this... and I have a doubt if this would be compatible with the -o option of fsevents.

[EugenMayer]

and I have a doubt if this would be compatible with the -o option of fsevents.

it wont, since -o aggregates the events, but does not tell you which happened anymore (AFAICS)
If you will try implementing all this event by even e.g. using the ruby gem fswatch i can tell you, you get such a huge CPU load ( thats not a assumption, i was using that before docker-sync and thats the reason i used the cli C version in docker-sync ). The CPU loads seems to be raising nearly linear with the number of files you watch.

So i am yet not sure, how you would implement this efficiently without having much higher drawbacks ( about 80% CPU load on a i7 4990k Desktop CPU with about 6k files ). So if you wil try this under your mbp, you will never use it again.

I know, thats the sad story.

first issue

--delete-before / --delete-after and do not use wildcards on sync ( not sure they did that on docker-osx-dev )

See a good explanation here http://askubuntu.com/questions/476041/how-do-i-make-rsync-delete-files-that-have-been-deleted-from-the-source-folder

[mickaelperrin]

I can confirm the CPU usage, this is the main reason I'm here working on docker_sync :) For Drupal case, it works well for simple files editing but it kills my MBP when bootstrapping a new project.

Thanks for pointing --delete-before and --delete-after, I can confirm that docker-osx-dev don't use these options nor the -oof fsevents.

[EugenMayer]

it is important , when defining the sync point in rsync, to not use /src/dir/* ... that wildcard is a huge issue for delete, use /src/dir/ .. thats what we do here.

[EugenMayer]

Way too many side effects here. I think this should be rather done by unison, if someone really needs this