> There is no source nor destination, it's a merge of two equivalent trees.
Let's say I have two systems in a programming project. On one of the systems, I have edited some files, but now realize I have created a bug I can't locate and I don't want to try to undo what I have done -- I just want system B to be returned to its original state, a state represented by system A, but with a minimum of file operations.
So I run a synchronization operation, and I tell the algorithm how to proceed. If I follow your philosophy --
"You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced."
-- then (using the default rules of two-way file synchronization), the edited files, the files I have ruined, files having newer dates than the originals, will be copied onto the original source tree, tree A, and I will lose the only remaining copies of the files' original states. If instead I delete the edited copies to avoid this, the originals will be deleted too.
So much for automatic file synchronization without the operator understanding and overseeing the process.
Your reply doesn't analyze file synchronization operations with enough depth to avoid such disasters.
You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".
I certainly agree with the latter, even if it has no bearing on the former.
> You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".
No, I have moved from specific examples to general examples, and general rules. The most general rule is that synchronization cannot be automatic and have a desirable outcome.
Let's say I have two systems in a programming project. On one of the systems, I have edited some files, but now realize I have created a bug I can't locate and I don't want to try to undo what I have done -- I just want system B to be returned to its original state, a state represented by system A, but with a minimum of file operations.
So I run a synchronization operation, and I tell the algorithm how to proceed. If I follow your philosophy --
"You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced."
-- then (using the default rules of two-way file synchronization), the edited files, the files I have ruined, files having newer dates than the originals, will be copied onto the original source tree, tree A, and I will lose the only remaining copies of the files' original states. If instead I delete the edited copies to avoid this, the originals will be deleted too.
So much for automatic file synchronization without the operator understanding and overseeing the process.
Your reply doesn't analyze file synchronization operations with enough depth to avoid such disasters.