On Mon, Feb 2, 2015 at 5:35 PM, Warren Young <w...@etr-usa.com> wrote:
> After sending that prior message, I did think of a way to allow retries > without inconsistency, but it would surely slow Fossil down: there could be > a mode that turns cloning into a replay of the master repo’s timeline. > > That is, every change made to the master gets applied to the slave, in the > order it was made. This means local files get updated multiple times, even > if later changes wipe out prior ones. The advantage is that after each > changeset is applied, the tree is again in a consistent state. I don't think it would be much of a slow down. All the artifacts will get sent, just the ordering will be more controlled. At the start of the first attempt to clone, send the oldest manifest and a cluster "listing" the remaining manifests in chronological order, plus as many of the files "listed" in the first manifest as will fit in the initial transfer. Then the client will process the manifests in the order they appear in in the "manifest clusters". (If there are too many manifests to list in a single cluster, the final entry in the cluster would be the ID of the next manifest cluster.) When attempting to resume, the client would include the pending "gimme" cards, also in the order the IDs appeared in the manifest clusters Other than insuring the client receives the manifests in chronological order, the clone protocol would operate as it currently does and would be compatible with clients that don't support resuming.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
