Post by J. RoeleveldPost by Frank SteinmetzgerUnison creates a local index of all files it syncronised. So when you move a
file around on one end, Unison will notice that because the file at the new
location has the same hash as the file at the old location. As a result, it
does not transmit the file anew to the remote host, but instead copies it
locally on the remote host.
Since Unison uses ssh underneath, you can use sshâs transparent compression
to speed up the transfer.
Unison sounds interesting. How does it handle conflicts (eg, file is changed on
both sides?)
I use Unison GUI on one of the two machines (on the other peer it's just a
program invoked from the ssh). When the analysis is complete, the GUI shows
what it would do to sync the machines, indicating the conflicts and giving
you the chance to choose what to do.
I believe it can be used from the command line or maybe even in batch mode
instead of GUI but I never did it that way.
You can set up a merge command to solve conflicts on the cmdline, such as
vimdiff. But when I set that, it blocks the GUI. Maybe I did something wrong
with the setup. Anyways, when I get a conflict, I make a backup of the file
locally, overwrite it with the remote and then do a conflict resolution with
vim.
In my every-day workflow, I usually only get conflicts in text files (logs,
notes, and so on). Binary conflicts are rare and usually due to recent
actions, such as editing an image or music file. In that case I can decide
on a per-case-basis which version to keep.
--
GrÃŒÃe | Greetings | Salut | Qaplaâ
Please do not share anything from, with or about me on any social network.
How does the Heisenberg compensator work? â Thank you, fine.