At some point in their career every programmer tries to write their own rsync. I must have written at least three — none of which are anywhere near as clever and reliable as rsync.<p>Why do we do this?
A simpler (and more efficient) equivalent to this script would be this one-liner:<p><pre><code> while true; do rsync -azP $PWD/ <remote>:$PWD/; sleep 2; done
</code></pre>
Or even better: <a href="https://code.google.com/p/lsyncd/" rel="nofollow">https://code.google.com/p/lsyncd/</a><p>lsyncd uses inotify/fsevents, meaning you don't have to traverse the filesystem to poll for changes.
While I can see how this can be useful, that means you'll constantly breaking things on the development server while you're writing code/testing. When working on projects alone I prefer to have a simple script that runs rsync with some predefined settings whenever I want to upload changes for someone to see (I also have an option to upload database). For multi developers environments I guess git would be the way to go.
For development, I run my VMs with Samba so that I can use whatever local tools to edit files remotely.<p>Edit: I like the idea - make something you need, not struggle with overly complicated sync algorithms/apps to achieve the simple result.
Because we have git, and with hooks also automatic deployment. Seriously, this is a really bad idea, and the only reason I can find to why we don't see many tools like this is because they break stuff. All the time.