On Sat, May 21, 2011 at 10:20 PM, Ron Wilson <ronw.m...@gmail.com> wrote:
> On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa <g...@atmarama.net> > wrote: > > On Sat, 21 May 2011 14:32:34 -0400 > > Richard Hipp <d...@sqlite.org> wrote: > >> Does anybody have any other suggestions on how to prevent the lose > >> of uncommitted work? > > > > Maybe not suggestion to prevent losing of uncommitted work, but I'm > > thinking about using 'stash' in such situation. > > Doing a fossil update should never delete uncommitted changed files. > Zed's post implies this happened. > Using Zed's repo, I think I have reconstructed exactly what happened. When he entered "fossil update" because of bug in the logic that figures out what check-in to update to, it tried to update to <no-such-checkin> which contains no files. So it dutifully went through and removed all the current check-in files. But: any files that had been edited locally would not have been removed. They would have been flagged as "conflicts" and left unchanged. So after the malfunctioning update, Zed would have had all his files removed, except for those he had edited. So, even though Fossil malfunctioned, safety mechanisms in Fossil prevented work from being lost. So far... What happened next is less clear. But some additional commands were entered, including "fossil update trunk" and "fossil revert". The exact sequence of commands is unknown to me and probably forgotten by Zed at this point too. But whatever they were, they managed to delete his edits. Note in particular that the "revert" command is a request for Fossil to delete your edits, so it was doing exactly what it was asked to do. Note further "fossil revert" can be reversed using "fossil undo", in case you happen to revert accidentally. But, unfortunately, there is only one level of "fossil undo" so if you do something else after the "fossil revert", your changes are lost permanently. To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing. > > That said. I routinely backup my projects so I am far less likely to > loose more than a day's work. This is not a matter of not trusting a > given VCS, whether Fossil, git, some expensive commercial VCS or any > other, it is simply a matter of prudence. Better to have multiple > backup systems as this helps mitigate the effects of failures in any > one system. > > I've never lost uncommitted work due to Fossil, in four years of heavy use. But I have certainly lost work due to an ill-conceived "rm" or "cp". More than once I have done an "rm" with some wildcard in the argument, only to realize, milliseconds after pressing "Enter", that I had just trashed everything I had done so far that day. It's a bad feeling. -- 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
