desync VS bitkeeper

Does something like casync (https://github.com/systemd/casync or https://github.com/folbricht/desync) serve any purpose or provide any advantage to propagating rpm changes over rsync?

Software that comes to mind for syncing lots of small files: git (and other source versioning tools), casync (https://github.com/systemd/casync) and a go implementation (https://github.com/folbricht/desync). Not really an answer and I can't think of a way to shoehorn that into your workflow, but maybe it leads you down a useful road.

Mentioning the more portable desync is obligatory: https://github.com/folbricht/desync

This is not historically accurate, even in the narrow context of Git branch names. Git was initially written as a replacement for an old source control system named BitKeeper. BitKeeper had a concept of a “master repo” (the main remote repo); all other copies of the repo were “slave repos”. Example from the BitKeeper docs. Git inherited that naming convention.

> git repositories don't have "slave" branches, just a "master' as in template or origin

That isn't true - master in git comes from master in BitKeeper which did have slave replicas.

https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/H...

Git was originally based on Bitkeeper which uses the terminology in that way, for example: https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask

Git was created as a replacement for BitKeeper. BitKeeper does use the terminology master/slave. Thus, Git's use of master is in fact a reference to master/slave, not a master recording.