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.

Why do we do this?

I will often 'reinvent the wheel' on my own time just to gather some more detailed understanding of what's happening behind the scenes. I never really use the stuff in production code, though.

I used to code PHP and made a transition to Ruby at some point. After programming Ruby/Rails for a bit I decided to create a rails-like MVC framework for PHP. There are plenty of those in existence. I could have just read the ruby code, which I did a bit, but I wanted to understand a bit better why certain decisions were made.

Doing that little exercise helped out a good bit with that.

It is a good learning/practice/appreciation exercise, if nothing else.

After trying to replicate some of rsync's functionality you discover edge cases and other complications you might never have thought about and appreciate all the more how well rsync manages to work for your specific use case and more generally.

:) in my defense, rsync was doing too much for my simple needs. I wanted to have a simple and customizable experience. While I agree with you (no little script can match the power of rsync) it's good to have alternatives.

A simpler (and more efficient) equivalent to this script would be this one-liner:

    while true; do rsync -azP $PWD/ <remote>:$PWD/; sleep 2; done

Or even better: https://code.google.com/p/lsyncd/

lsyncd uses inotify/fsevents, meaning you don't have to traverse the filesystem to poll for changes.

Nice suggestion. I didn't use inotify because macosx doesn't have it and nodejs equivalents eats too much CPU for some reason. I tried to make it as simple as possible.

There are some hoops to jump through but I've got lsyncd working on my Mac. I think you have to compile it with fsevents. I think the README actually details what you need to do.

running rsync every 2 seconds on a medium/large project might be a little intense since it compares each file looking for changes.

It only needs to compare actual file contents if the file properties (dates, size, ownership, rights) have altered with the options used in this example so it would only need to perform directory reads in the case of no such changes. Of course for a very large project this could still be significant, but much less so.

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.

Edit: I like the idea - make something you need, not struggle with overly complicated sync algorithms/apps to achieve the simple result.

This is actually not changing the files on production but for using a development server. In my case, we don't have local servers. We have development servers that are identical to production servers.

I manage my changes from my local so I can use any editor I want in the mean time this script uploads all my changes to development server.

I think this is the general use case.

This is what vagrant was built for, so that you can run a full development environment locally and then push changes to staging/production server using git (and hooks, if you want to automate the process), when you have something working and want to show it off.

Using this technique you're stuck, because only one person can develop on the same project without interfering with each other. Also, git-hooks are not /that/ hard to use, you should really look into it, as it solves two problems: You have version control and you have easy deployment.

Oh no, you misunderstood. On our project we use git, and git hooks. however we use githooks only for linting and such. We deploy using a different system.

We have development servers for each developer like 'username.dev.myapp.com' so you don't have to install the application on your machine. Most people work on the server using 'ssh: screen/tmux - vi/emacs', but I want to work on my local because it's faster. So I needed a system to upload my changes to my remote box. and commit my changes from local.

Most companies use this technique so that you know how your code will behave on production while developing it, because it has the same exact architecture.

I hope it's more clear now. It's funny that you would think I don't use a version control system :) what year is this.