On Tue, 4 Oct 2011 14:06:54 -0400 Richard Hipp <d...@sqlite.org> wrote:
[...] > (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. Just a thought: what if `fossil status` showed the size of the affected files? Something akin to what `vdir` or `ls -l` do but using the metadata which is to be stored within the fossil repository upon commit. That would be overkill for `fossil changes` but `fossil status` already shows extended information so it seems that making it "more extended" might turn out to be useful. [...] > (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. I think this has been discussed already, but to me it appears something resembling Git's "reflog" functionality could be of help in the cases like this one. The basic idea is to implement a storage (kept in the checkout database) for things `fossil undo` operates on, but with a time-based expiration instead of being a stack (Git uses 30 days by default IIRC). Conceptually Git's reflog looks just like a single line of history ordered by time of events forming it. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
