On 13 March 2015 at 05:59, Jan Nijtmans <jan.nijtm...@gmail.com> wrote: > I read in this thread) with Richard's conclusion that work has been lost > due to fossil, but David Mason should have the final word on that (the > DELETE's in David's original story meant that those _unchanged_ files > were removed from the working copy, but they still were in the > repository even though they were invisible to the students).
As I said privately to Richard, I think the claim that Fossil has never lost user data is intact. I will have the TA: 1) update to the student timeline, 2) mv the student files to a safe directory 3) update to the proper timeline 4) mv the files back 5) add/commit the files The only thing that will be lost is meta-data - the sequence of checkins. But, in fact, even THAT isn't completely lost... it's still in the repo and can be accessed via the UI. And in fact, with some SQL magic, even that could be recreated (with a time warp because the student's commits would follow the TA's statement that they weren't there). That's not worth it in my case, but it could be done. If there were files on both of the timelines, it would have been more complicated, but still doable. > Thanks to Tontyna for her excellent analysis, which made it > (at least to me) fully clear what really happend here. Yeah! I was pretty sure what had happened, but when she recreated the scenario it was a huge reassurance, and obviously helped everyone else recognize what was going on. I would certainly support the idea that all future versions should refuse to work with a newer schema - at least by default... perhaps there should be a --force option with loud warnings about possibly corrupting your repo. ../Dave _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
