On 22 July 2014 17:29, Andy Bradford <amb-fos...@bradfords.org> wrote: > 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].
ahh, right :-) Now everything works (breaks) perfectly. I tried to mimic the actual situation I had earlier (http://lists.fossil-scm.org:8080/pipermail/fossil-users/2013-August/013629.html), except on 1 host like you suggest, using 2 clones. I don't / didn't use branches other than trunk (which still breaks, using your example - good). Effectively committed the 1500 files onto trunk from within the 1st clone's workdir, and didn't follow it by an additional commit. Sync from within the 2nd clone's workdir received iirc 161 out of approx 1500 artifacts, after which the timeline didn't show the commit. Following that by a single added/committed file from within the 1st clone's workdir again, and a sync from within the 2nd clone's workdir, retrieved everything up to and including the last single-file commit. So... this seems exactly what I saw happen here at that time; thx again for the effort, I'm very happy this seems pinpointed! Michai _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
