Re: Reasoning behind convert-ly rule for stable update?

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> That's nice and all, but irrelevant to the problem of reducing the
>> amount of work convert-ly has to do on unchanged files.
>
> Oh phooey.  Of course update-with-convert-ly can generally start with
> the last stable safely.  Nothing in the tree will be older than that.

Ok, here is what _might_ have been the idea from the code.  Suppose that
I have a file for version 2.15.5 and I run convert-ly 2.17.8 without
options on the file, and there is one conversion applied at 2.15.11.
Then instead of claiming the file to be 2.15.11, stuff gets rounded up
and 2.16.0 is claimed instead, just losing a bit of history within
unstable versions.

That would make some sense.  It would not make things significantly more
efficient, but it would throw away old unstable version history which is
not all that interesting.  But the code currently does not appear to
work this way: it seems to promote even an unchanged 2.16.0 to 2.18.0.
And besides, updates when there are _no_ changes should be skipped in
either case.  I'll try to see whether I figure something out in that
direction.

-- 
David Kastrup