Multiple "synced" folders

appnexus / sicksync

Don’t accept the available as the preferable. Go the extra mile with extra speed.

Apache License 2.0

68 stars 11 forks source link

Multiple "synced" folders #12

Closed joelgriffith closed 9 years ago

joelgriffith commented 9 years ago

It'd be nice to have multiple folders sicksynced independently. This would likely require some config modifications...

joelgriffith commented 9 years ago

Might be nice to have the sicksync wizard save configs locally (similar to how jshint operates), and if none is found bubble up to the HOME directory to sync.

chrisdopuch commented 9 years ago

joelgriffith commented 9 years ago

I've been thinking a lot about how to implement this, and it's fairly trivial as far as the client goes (just a new config file, new option to create a project, and some reducing to find the nearest config), however it get's a bit challenging from the remote perspective.

It has no idea about which project is being synced. Currently, it just assumes that you're going to sync one project (which is the global one). This gets further complicated by the fact that the remote machine can be started manually or automatically. If it's started manually (via the CLI), then it could be listening in the wrong place and updates that come in would hose everything.

I think I'll need to write a proposal for this as it's a fairly complicated feature.

joelgriffith commented 9 years ago

Also, the JSHint behavior is something I'm leaning against. The .jshintrc file is nice because it can be checked in and enforce rules about how that project is linted, but in the case of sicksync every .sicksync-config.json file is different and will add noise to a projects .gitignore.

Since care has to be taken with the remote machine(s) in how sicksync works, I'm starting to lean towards extending the CLI for handling multiple projects.

sodiumjoe commented 9 years ago

i would propose git as a template for handling configs (same as jshint) and remotes (remotes are defined in the per project config, including a default, then used as a command argument.

joelgriffith commented 9 years ago

From the conversation had on Monday, the following would change:

Configs

Removal/Deprecation of remote configs. Port will no longer be exposed as a parameter (we might want to do some port checking so we don't end up with odd errors).
Projects will now have their own configs (similar to JSHint/Git), and potentially have a Global config that sources from these two in case we want to launch multiple projects. These would be indexed by host + project location or some other unique identifier.

CLI

Deprecation of sicksync-remote. The recommended workflow will be shelling into the remote machine and starting the server (sicksync already does this).

Web Sockets

Sending the full file path (destinationLocation + the relative path) to the remote machine.
Potentially stopping segfaults by unwatching during a big sync.

joelgriffith commented 9 years ago

Feature is complete in 2.0.0