Is -without shunning- the 24MB-version still present in your local repository? Won't is be synced sooner or later anyhow now? -- Jos Groot Lipman
_____ From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp Sent: dinsdag 4 oktober 2011 20:07 To: fossil-users Subject: [fossil-users] Why you should not shun Here is a true story, from just a few minutes ago, about how a very nearly lost 5 hours of intense work due to an ill-advised shun, and was only saved by the "fossil undo" command.... I keep all of my OpenOffice slide presentations in a private Fossil repository, so that I can develop presentations on my Ubuntu desktop, then sync to my macbook to take on the road. I spent this morning working on one such presentation. Part of my changes this morning involved a image that I copy/pasted from wikipedia. I didn't realize it at the time, but the image was a 24MB PNG. Everything worked fine. I saved my work and checked it in. But after checking in, Fossil then tried to push the changes to my master repository on a server at Hurricane Electric. 24MB of uncompressible image takes time to go over ADSL. So I realized there was a problem and cancelled the sync. How to fix this? I down-sampled the image to a lower resolution JPEG, reducing its size from 24MB to about 400KB. But I still had the old version stored in my local repository. "No problem", I thought. I'll just shun it. Which I did. Then I did "fossil update previous" so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed. Fortunately, I later realized that I could do "fossil undo" to reverse the update and get my changes back. Three lessons: (1) Know what you are checking in before you do the check-in. If I had simply paid attention to the size of the *.odp file that I was committing, I would have realized that it would be a slow syncer. (2) Don't use shun. Even if you think you know what you are doing, you are very likely to get into trouble. (3) If you ignore the previous two warnings and find yourself in a bad situation, don't panic. Think about where you are and plan your recovery carefully. If I had panicked, I might have entered other Fossil commands which would have purged my undo stack. As it was, I walked away from the keyboard and later realized that a "fossil undo" would get my old files back. Learn from my mistake: Don't shun on a whim. The only reason to shun is to remove truly harmful content, such as spam. I should have just let the sync proceed even if it was slower than I would like. If you must shun, plan your shuns very, very carefully. After shunning, test your repository before syncing. Don't do something you will later regret. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
