[Unison-hackers] big picture: is use of rsync actually useful

[Greg Troxel]

There's an issue on github about the impacts of an ABI break imposed by
rsync 3.2.4, when using an external copy program.  Figuring out how to
adjust the code to deal with that (or not to, as there is an existing
preference) is in scope for the ticket, but there's starting to be
discussion that is beyond the scope of the bug and that doesn't meet the
guidelines for issue tracker use.  So I'm moving it here from
  https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/865__;!!IBzWLUs!TLqS5c86Cw9Ep6TJwLZ74bStOXgXto1L8El5bcEzLHohFy_uGaVwdbOKUIMbt7D6BL3Vm1q0lXJxVaVD3kG2gmKB$ 


The first question, extended slightly, is:

  Unison allows using an external copy program via copythreshold, on the
  theory that this is more efficient.  Is there any recent evidence that
  this is actually true?   If not, should we just remove the external
  copyprog mechanism?   If so, would it make sense to improve the
  internal sync and still remove the external support?



The second question asked in the ticket by @rrthomas was:

  Why not remove Unison's internal copying, and just use rsync, replacing
  copyprog and copyprogrest with a single preference to specify extra
  rsync options? (I bet there are good reasons, but I'd like to know what
  they are!)

My reaction is

  Rsync is not a dependency right now.

  Right now unison works very reliably and adding a dependency seems
  likely to decrease reliability, especially given upstream's
  willingness to break the ABI.

  We don't have any reason to think people are using external rsync much
  (because it took a year for the problem from the ABI break to be
  reported), so there's no reason to think the external rsync path is
  well tested.

  Therefore I wouldn't want to even seriously consider making external
  rsync the only approach.