Re: [Caml-list] File synchronization implementation(s) in OCaml?

[Hendrik Boom <hendrik@topoi.pooq.com>]

On Thu, Feb 08, 2018 at 07:42:57AM -0800, Evgeny Roubinchtein wrote:
> Thank you everyone for all the responses and pointers to artefacts and
> papers.
> 
> Cedric, that is an excellent point; thank you.  My current intended use is
> having the user edit file(s) on host A using a text editor, and, when the
> user saves a file, having those edits reflected as quickly as possible in
> the corresponding file on host B.  So, my primary measure of performance is
> the speed of update: I want the time between the events "the user, who runs
> the editor on host A, has issued a command to the editor to save the file"
> and "the contents of the file the user has just saved on host A and the
> corresponding file on host B is identical" to be as low as feasible (there
> is a mapping between file paths on hosts A and B).  Sometimes, the user
> will create a new file on host A; then the file's contents needs to be put
> as quickly as possible into the corresponding location on host B.  One
> other consideration is that occasionally   the user may have their text
> editor save a number of files in quick (at least in human scale)
> succession: for example, the user issues "M-x compile" in Emacs, and Emacs
> offers to save all modified buffers before running the compilation: in that
> case, the total time to propagate the changes to all modified file(s)
> should be as low as possible.  So, to summarize:
> 
> 1. One-way synchronization is acceptable (I may find out otherwise with
> experience, but, for now, I am willing to make that assumption)
> 2. It is always known which file(s) have been modified.
> 3. It is probably feasible to plumb through the information about what
> part(s) of of a file were modified for each file from the text editor to
> the updater, if that helps with the speed of the update.  The editor
> usually "knows" what has changed, because it needs to be able to undo the
> changes.
> 4. The relevant metric is the speed of the update.
> 5. Sometimes changes to more than one file may be saved in quick (human
> scale) succession.  The relevant metric is still the speed of update to all
> files.

Unless your requirements are very different from mine, I suspct you want 
distributed revision management.  The system I use for that is monotone.  
Once set up it's a lot easier to use than git.


-- hendrik