> 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

Reply via email to