You clearly haven't tried to use rsync, which has its name for a reason -- it's a synchronization utility.
Like many others, e.g. Dropbox, Unison, Git-annex. Just because "rsync" has sync in it's name doesn't mean it's the only syncing model possible.
All synchronization operations must know which is the source and which the destination.
In rsync, yes. In others, no.
SO which word is confusing?
No confusing word. The only confusion is in the assumption that sync == rsync. It's like saying that all cars work like the Model T.
Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.
Nope. You never have to tell Dropbox, Unison or git-annex which is the source and destination. In the latter, I just do "git-annex sync", and both are synced with each other.
>> All synchronization operations must know which is the source and which the destination.
> In rsync, yes. In others, no.
False. In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do. In no case can the operator use such an algorithm without understanding what rules it intends to apply.
> In the latter, I just do "git-annex sync", and both are synced with each other.
Read the above example. These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.
In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do.
I have no idea why are you bringing versioning into this conversation.
These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.
I don't know what do you mean by "get it right". That's a subjective concept.
All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.
> I have no idea why are you bringing versioning into this conversation.
I can see that. Okay, let's say that someone has a corrupted music track on his iPhone, the track won't play, and even though it has a newer date than the original on his desktop archive, he needs to overwrite the new-date bad track with the old-date original.
> All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.
All I am saying is you're not thinking about this with enough depth. In the above example, a modern, sophisticated two-way synchronization algorithm will overwrite the old-date good track with the new-date defective track unless the operator understands how synchronization works and prevents this default outcome.
> I don't know what do you mean by "get it right". That's a subjective concept.
No, it is not -- unless you think everything is a matter of opinion and there are no shared objective truths. And if you believe that, why do you even bother to post in public forums, forums that exist on the premise of the reality and utility of objective, shared truths?
Like many others, e.g. Dropbox, Unison, Git-annex. Just because "rsync" has sync in it's name doesn't mean it's the only syncing model possible.
All synchronization operations must know which is the source and which the destination.
In rsync, yes. In others, no.
SO which word is confusing?
No confusing word. The only confusion is in the assumption that sync == rsync. It's like saying that all cars work like the Model T.
Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.
Nope. You never have to tell Dropbox, Unison or git-annex which is the source and destination. In the latter, I just do "git-annex sync", and both are synced with each other.