search

xybu / onedrive-d-old

Microsoft OneDrive client on Linux.
http://xybu.me/projects/onedrive-d/
GNU Lesser General Public License v3.0
819 stars 142 forks source link

"Slave" Mode #81

Open kpj opened 10 years ago

kpj commented 10 years ago

Hello, What do you think about adding a "Slave"-Mode, i.e. a mode which does not consider the local versions and always overwrites them with the remote one. This might be e.g. useful as a mirroring option where one would under no circumstances lose the remote progress.

Is there maybe already a way to accomplish this?

xybu commented 10 years ago

I think, if you don't change the files in the local repo, then the program is already running in the "slave" mode you want. If you change the files in the local repo, then "slave" mode means you always lose the local "progress". Is there a specific scenario in your mind? Please share with me so we can further the idea :)

kpj commented 10 years ago

I agree that this might be a superfluous feature for the exact reason you stated. I just like to have the additional safety of knowing that even if something changes by accident, nothing would happen to the remote repository.

paulstelian97 commented 9 years ago

Some "pseudocode" to get it: 1) Check the local and remote files, and find differences. How should they be tackled? 2) In normal mode, the file which was modified more recently wins. In slave mode, remote files win. 3) Commit the difference to the other endpoint, so that the winning file remains unmodified. (note that the term file also includes folders)

xybu commented 9 years ago

Just finished the non-GUI part on future branch. I felt that the algorithm is conservative enough to not let you lose remote data (when not 100% sure, program keeps both). But file managers are annoying when they change mtime attributes. A slave-mode may be just to prevent uploading data (or may we call this "mirroring" mode?).

kpj commented 9 years ago

@paulstelian97: Regarding your first point; would you suggest not simply overwriting the older file, but rather applying some merging strategy (e.g. similar to git merge)?.

@xybu: Your description of a "mirroring" mode seems similar to the way paulstelian described it in 2) and 3), right? This looks like a sensible approach!

paulstelian97 commented 9 years ago

@kpj It's even better to have a good merging strategy, as long as it doesn't overcomplicate stuff, yeah.