On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote: > 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). >
BTW, chiselapp.com still use version 1.25 release. The same problem could happens easily when using the "Clone Repository" option if the source repo is created without initial empty check-in. -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
