2015-03-13 8:49 GMT+01:00 Stephan Beal <sgb...@googlemail.com>: > Richard mentioned earlier that he will remove the "no initial commit" bits, > which will (theoretically, at least) eliminate this problem for future > versions. i would hate to see it go
+1 > (not enough to raise a fuss about it), > but it should never have ever been made the default, to avoid compatibility > problems like this one. There was a long thread related to this on May 31st, > 2014: > > https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html The source of this problem was the (past) assumption in the code that the initial commit has rowid=1 and it doesn't contain any files. This bug was fixed here (16 months ago, available since fossil 1.28): <http://fossil-scm.org/index.html/info/6791ad1185f374dc> If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Therefore I respecfully disagree (based on what 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). Thanks to Tontyna for his excellent analysis, which made it (at least to me) fully clear what really happend here. Regards, Jan Nijtmans _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
