

Show HN: Sync.js – Upload changed local files to remote server - serkanyersen
https://github.com/serkanyersen/sync

======
sambeau
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?

~~~
robflynn
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.

------
dansimau
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/](https://code.google.com/p/lsyncd/)

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

~~~
serkanyersen
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.

~~~
res0nat0r
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.

------
skimmas
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.

------
JimmaDaRustla
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.

------
vegardx
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.

~~~
serkanyersen
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.

~~~
vegardx
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.

~~~
serkanyersen
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.

