3 ms·

I am curious, why would you go into the project thinking rsync and not git? It seemed to me most of these syncing folders are really a special case of source c

I am curious, why would you go into the project thinking rsync and not git? It seemed to me most of these syncing folders are really a special case of source code control.

Afton 10y ago
I wasn't involved in these design discussions early on, and Skydrive certainly didn't use rsync, this was just meant as an example of "this is essentially a solved problem, we just need some UI". It isn't, and presenting it as such just gets you into a bad situation.
- alphapapa 10y ago
  But Dropbox doesn't handle any merging of changes; any conflicts are left for the user to resolve. In this way it's basically an automatic version of Unison, which is exactly "some UI" around a "solved problem." Right?
  - Afton 10y ago
    I'm not familiar with Unison, and have no idea how successful it is, nor where it falls down.
  - PeterisP 10y ago
    It doesn't handle merging of changes within files, however, if you take a step back, consider that you're essentially merging lists of metadata (with hashes of blobs), not just uploading these blobs; and because the systems that need to be synced are distributed, not always connected, and users want to read/write all of them you get the limitations of the classic CAP theorem. E.g. the quite feasible scenario with two computers, both partially synced, and both getting files changed/added/removed/moved while the sync is happening. Consider applications creating temporary files while a document is being edited, and expecting to be able to create those files... and then it results in some app being unable to open the same document because it's "already open" on another machine. There are all kinds of interesting conflicts and race conditions possible, and you need to resolve them all in some way that doesn't weird out the users.
ssalazar 10y ago
Stock git explodes when dealing with binary files that are above a certain size or are changing frequently. So forget about photo collections, shared Photoshop files, or any other non-text document formats. The workarounds had a lot of pain points for a while (that maybe are fixed now in 2017, haven't explored that recently).
- protomyth 10y ago
  I was more thinking the concept of source code control than the specific, but used a specific since a specific file transfer program was mentioned. Some source code control programs handle binaries just fine.

I am curious, why would you go into the project thinking rsync and not git? It seemed to me most of these syncing folders are really a special case of source code control.

Afton 10y ago

I wasn't involved in these design discussions early on, and Skydrive certainly didn't use rsync, this was just meant as an example of "this is essentially a solved problem, we just need some UI". It isn't, and presenting it as such just gets you into a bad situation.

alphapapa 10y ago
But Dropbox doesn't handle any merging of changes; any conflicts are left for the user to resolve. In this way it's basically an automatic version of Unison, which is exactly "some UI" around a "solved problem." Right?
- Afton 10y ago
  I'm not familiar with Unison, and have no idea how successful it is, nor where it falls down.
- PeterisP 10y ago
  It doesn't handle merging of changes within files, however, if you take a step back, consider that you're essentially merging lists of metadata (with hashes of blobs), not just uploading these blobs; and because the systems that need to be synced are distributed, not always connected, and users want to read/write all of them you get the limitations of the classic CAP theorem. E.g. the quite feasible scenario with two computers, both partially synced, and both getting files changed/added/removed/moved while the sync is happening. Consider applications creating temporary files while a document is being edited, and expecting to be able to create those files... and then it results in some app being unable to open the same document because it's "already open" on another machine. There are all kinds of interesting conflicts and race conditions possible, and you need to resolve them all in some way that doesn't weird out the users.

ssalazar 10y ago

Stock git explodes when dealing with binary files that are above a certain size or are changing frequently. So forget about photo collections, shared Photoshop files, or any other non-text document formats. The workarounds had a lot of pain points for a while (that maybe are fixed now in 2017, haven't explored that recently).

protomyth 10y ago
I was more thinking the concept of source code control than the specific, but used a specific since a specific file transfer program was mentioned. Some source code control programs handle binaries just fine.