Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200: > I can't seem to reproduce what you describe - either that, or I'm > missing the point (did you mean 'merge' as in 'fossil merge'?). I'm > assuming you left out 'fossil add' (or 'addremove') twice in your > example.
Yes, I left out a few steps (sorry). It was assumed that the 1500 files already exist in the repository and the changes are just updates (but essentially a 100% rewrite of the file due to the randomness). Also, the entire lump of changes has to be large enough that max-download comes into play and there are multiple sync operations that occur as a result during the checkin. I don't think it matters whether these are new files or modified files (I just used edits because I was trying multiple variations), so after generating all the files, you could do ``fossil addremove'' to get the big change set. > I tried your example on a single host, hopefully to exclude complexity > added by any physical network. (Do you think it's necessary to use 2 > different hosts to reproduce the issue like you described?) I cloned > using http:// before adding files, and then updated from within the > cloned repo's workdir. More steps I left out... No, I did this all on one host. I created the repo and started fossil server with the repo. Then I cloned it 2 times. In one clone I made the changes and then after the last checkin, I did an update in the second clone. It never received the artifact for the checkin (because it wasn't on the unclustered artifact and not mentioned in any other manifests). Also, as far as the Fossil version is concerned, though I think any should suffice, I was using [619fa857c933]. Thanks for attempting to confirm the problem. Andy -- TAI64 timestamp: 4000000053ce837e _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
