Thus said Ron W on Mon, 16 Mar 2015 12:21:45 -0400: > > The requirement, specifically, is that the first artifact that the > > server sends during a clone, must be a checkin, or older Fossil > > clients will end up in this state. > > Could the server side be modified to insure the first artifact sent is > the first manifest?
The server relies on the fact that the first rid in the blob database is a checkin. I suppose it could be more careful and decide to error if it discovers that rid=1 is not a checkin. fossil new currently guarantees that rid=1 is a checkin, but I'm still not convinced that deconstruct/reconstruct makes this guarantee. So as a protective measure, the server side of the clone could check and return an error if it finds that its repository does not have rid=1 and type=ci. Or, a new ordering algorithm could be devised. Right now, the order of artifacts delivered during clone is determined by the sequential ordering of items in the blob table (which is why rid=1 has to be a checkin). The cloning sends a clone_seqno, which is basically the last item out of the list of blobs that has been sent. So a client only needs to send back the clone_seqno to receive the next batch of artifacts. If cloning could guarantee that the first artifact sent is a checkin, or return an error if there are no checkins, this might make it possible to have repositories that have not the ``initial empty check-in.'' But basically, the onus is currently on whatever populates the blob table to ensure that the ordering is correct because the clone protocol just naively takes them in sequential order. Andy -- TAI64 timestamp: 4000000055071bac _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
