big picture: is use of rsync actually useful
Greg Troxel <[email protected]> Sat, 11 Mar 2023 09:22:14 -0500
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <[email protected]> |
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.