Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Why need for LiveReload? Support for inotify? Two-way sync? Ignore? #7

Closed
duro opened this issue Dec 16, 2014 · 3 comments
Closed

Comments

@duro
Copy link

duro commented Dec 16, 2014

A have a few questions, as I have been looking for a more reliable code sync solution for some time (mostly for use between a local OS X file system, and a VM running inside VirtualBox on the same machine).

1 & 2: What is your implementation plan for Live Reload? Is this because the remote mirror does not fire inotify events for watchers like Grunt and Gulp to pick up?

3: Does this, or could this ever, support two-way sync? ie. I am SSH'd in to the dev box, and I do an NPM install --save-dev (which updates the package.json). Could a change on the remote be mirrored back to the local?

4: Can I ignore files to be mirrored?

Great work on the package, and I look forward to more to come.

@joelgriffith
Copy link
Contributor

Hey! Thanks for the questions, let me try and answer you here:

1 & 2: What is your implementation plan for Live Reload? Is this because the remote mirror does not fire inotify events for watchers like Grunt and Gulp to pick up?

I originally had Browser-sync baked into this project, but it was leaking memory somehow (I'm guess it's wrapper around vhost). My initial plan is to naively fire a reload whenever it sees a file-change. I do like the idea of hooking into something like inotify and letting consumers do what they will with the events. I'll have to investigate that option.

3: Does this, or could this ever, support two-way sync? ie. I am SSH'd in to the dev box, and I do an NPM install --save-dev (which updates the package.json). Could a change on the remote be mirrored back to the local?

I imagine that this could happen, with some work. It's currently structured as a master -> slave relationship, but it's possible to do it bi-directional since it's Websocket backed. If there is enough demand for two-way mirroring, then I could see this becoming a feature.

4: Can I ignore files to be mirrored?

Totally. In the initial setup, the wizard will ask for a comma-separated list of globs (or straight file-paths) relative to the directory your syncing. Example: I'm in ~/Projects/ws and I want to ignore git, so I'd add .git/* as a pattern to ignore. It uses minimatch under-the-hood to ignore. If you've already done that, then just edit the config file. sicksync -c should open the config file and you can edit as needed. You'll have to sync this manually, however :(

Thanks for the kind words. I'll definitely be looking at the inotify for creating some sort of hook for other build processes.

@duro
Copy link
Author

duro commented Dec 16, 2014

I'll definitely be looking at the inotify for creating some sort of hook for other build processes.

If you are actually "writing" the files to disk, then you probably already have inotify. inotify is just a linux kernal feature that fires events when file system triggers occur. The only time you don't get inotify is when you have a file system which exists outside of the native FS on the Linux box (ie. NFS, VBoxSF, other network attached file-systems)

@duro
Copy link
Author

duro commented Dec 16, 2014

I went ahead and opened a feature request for bi-directional sync here #8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants