On Wed, Nov 26, 2014 at 5:53 PM, Richard Hipp <d...@sqlite.org> wrote:
> The new field is used to ensure that one does not "purge" a baseline > manifest without also purging all its deltas, since to do otherwise would > render the deltas unusable. It should be impossible to do that because the > purge command removes a checkin and all its descendents and all deltas of a > baseline manifest must be decendants of the baseline. But it feels nice to > have that extra check in place, just as an added safety measure. In a > version control system, it is VERY important that errors and/or bugs not > destroy history. The schema change simply adds another layer of defense to > make sure that never happens. > It seems to me that this extra check is important, since it is not a redundant check, only checking for a case that in the current flow cannot happen. A future enhancement may somehow allow delta manifests from a baseline manifest that is not a direct ancestor, or may upgrade the purge feature to allow purging part of a timeline instead of the whole thing, and by then this detail may be forgotten. Or am I excessively paranoid, too? So should I go forward with the schema change and make everybody run > "fossil rebuild all" for the first time in recent memory? > I don't see the big deal in having to do a rebuild, but maybe that is because I don't have any extremely large repos, or even that many small ones. P.S. If changing the schema is indeed a big deal that you would rather avoid as much as possible, and if you do decide to go ahead and change it now, maybe you can have a look at this bug ( http://fossil-scm.org/index.html/tktview?name=d26a9d9e2b) too. I am not sure how to fix it myself, but I think that fixing it may require a schema change, and if so you might as well do all the changes in one release. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
_______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
