> On May 27, 2016, at 12:26, Andy Gibbs <andyg1...@hotmail.co.uk> wrote: > > Hi, > > I've just had a very, very odd experience with fossil. I'm running version > 1.34. > > Let me first explain what I have done. > > I cloned a respository off our server. I then went into the clone's web UI > and disabled the auto-sync feature. I then made 7 commits, the first of > which caused a trunk fork which I then "repaired" by branching the old > tip-of-trunk that caused the fork. I then committed two commits to the new > branch, then realised that I'd committed the wrong code, so shunned the last > two commits, rebuilt the respository, unshunned the sha1 signatures, rebuilt, > then recommitted the last two commits using the correct code. > > Ok, a little complicated but nothing too out-of-the-ordinary, I hope. > > Except ... now I have two utterly random commits in my cloned repository - > both seemingly from the sqlite repository: > > 2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, > version-3.8.7.4) > 2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh)
If you commit a file that looks like a fossil manifest, then fossil treats it as such and displays the commits listed therein as if they happened in your actual repository. Or something. I had this happen to me too a while back when I did the same thing, importing the SQLite tree wholesale into another fossil repo. Drh said at the time that there's no "real" corruption. Sent from my iPhone > > Now, it is true that I have a clone of the sqlite respository on my server > too ... but I haven't yet synced with the server. Absolutely no server > communication has happened since my initial clone. And these odd artifacts > were definitely not there (or, rephrased, definitely not showing) when I was > mid-way through all of this work, and are not there on the server's copy of > the repository either. > > Unfortunately, I cannot say exactly when these artifacts appeared, but my > hunch would be somepoint around the shunning/rebuilding process? Does this > even make sense?!? > > Worse, I am left not sure whether to simply shun the two random artifacts and > then push the changes to the repository up to the server. It has taken the > best part of a day to get all these commits in and it represents about 6GB of > source files (the repository has doubled from ~700 MB to ~1.5 GB) requiring a > lot of manual "fossil mv"s to synchronise many moved files (fossil doesn't > yet support a git-like auto-mv-detection sadly). > > Any idea how I can easily check the validity of my repository? I have done > the obvious which is to check out each of the recent check-ins and compare > them with the original source folders, but what I don't know is whether the > structure of my respository is damaged in some way... > > Help!!!! :o) > > Thanks! > Andy > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users