On Friday, August 24, 2012 6:57 PM, Richard Hipp wrote: > On Fri, Aug 24, 2012 at 12:45 PM, Andy Gibbs wrote: >> >> Hi all, >> >> I've had the following error, and I don't know why and I don't know what >> it really means and I don't know what to do about it! (yes, I really >> don't know!) >> >> ERROR: [mefs1a.c] is different on disk compared to the repository >> NOTICE: Repository version of [mefs1a.c] stored in >> [file-15c57bdd987a757d] >> c:\fossil\fossil.exe: working checkout does not match what would have >> ended >> up in the repository: e641896af05b54f1481aa9d556a5c24d versus >> a9b7421a3d7ce833ea78e9cc43b41e18 >> >> In terms of how this has come about: nothing out of the ordinary, I >> assure you: simply editing and committing. >> >> Does this mean there is a hash conflict? And what can I do about it? > > When you do a "fossil commit", Fossil starts a transaction on the > underlying > relational database. Then it starts making changes to the database to > insert your new check-in. After it thinks it has finished, it goes back > and does lots of double-checks to make sure that what it added to the > database is the same is what you have on disk. It is one of these > double-checks that failed. > > After the failure was detected, the database transaction was rolled back > so > that no harm comes to the repository. This is a safety feature of Fossil. > > Apparently when it looked at the file that was committed to the repository > as "mefs1a.c" that file was different from what it saw on disk. The > version of the file that it tried store in the repository is now copied > into file-15c57bdd987a757d. Can you run a diff on "mefs1a.c" and > "file-15c57bdd987a757d" and let us know how they differ?
Well, it is certainly good to have the safety checks; I wonder how I've tripped it! I did do a quick diff before I posted the original question, and the two files were noticeably different, not in a corruption way, but in a way to imply two different versions of the same file. It was the end of my day so I didn't have a chance to really delve into which older version was causing the conflict (I can check this tomorrow and post again regarding this), but I can certainly say for sure that no file changing was going on while doing the commit (at least as far as I am able to control: i.e. no editor open, etc.). Is it possible that fossil would try to commit a version not actually on the hard-drive? I would have thought not, but the differences were not in terms of line endings or whitespace but really different "words" (macros were renamed and mefs1a.c had the correct names and file-15c57bdd987a757d had the incorrect/old names). This is what made me think of a hash conflict (however unlikely that may be in actual practice). Does this help? I can get more info tomorrow when I pop into work. Other info: I'm using the latest version of fossil downloaded from the website (1.23 from 8/8/2012) on Windows XP. Thanks! :o) Andy _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
