Re: Make convert-ly -d only ever update on changed files (issue 31830043)

[dak]

Reviewers: Keith,

Message:
On 2013/11/25 06:37:35, Keith wrote:
> I'm fine with this,
> but then we would probably want to run convert-ly without the '-d'
option on
> Documentation/snippets, upon creation of version 2.18.0.

> Maybe there is a way to get the behavior of "round-up-to stable
version"
> triggered by the (usually dummy) convert-ly rule for that version.  I
can only
> think of kludgy ways right now

The "dummy" convert-ly rule is actually dummy when used with -d: it is
not specially parsed or anything.  The update is instead triggered by
the version number of the last checked rule.  For that reason, a number
of issues with convert-ly rule for 2.19.0 have not been uploaded by me:
they contain thousands of gratuitous changes.

> https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py
> File scripts/convert-ly.py (left):


https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#oldcode295
> scripts/convert-ly.py:295: # check the y in x.y.z  (minor version
number)
> This did cause me confusion recently, while preparing the keySignature
> name-change that I had postponed for the 2.19.x branch.

> I knew about the mechanism to update to a stable label using a
dummy-rule
> mechanism in convertrules.py, but this hidden mechanism surprised me.
Why, I
> thought, does it know about 2.18.0 when that version does not exist?

Because that's the you have considered a rule beyond that.

> https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py
> File scripts/convert-ly.py (right):


https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#newcode306
> scripts/convert-ly.py:306: last = next_stable
> The old code was there so that the \version ".." is updated for a new
stable
> version <http://codereview.appspot.com/2642041/#msg3>

> It looks like the new code does not perform this function.

Yes, that's the intent.

> It takes some patience to understand what this does, either by reading
the
> doc-string or the code, because it is a sophisticated behavior, and I
do not
> understand its purpose or motivation.

This basically comes into play only when importing stuff.  Note that
stuff like the LSR runs on stable versions, and that's basically what
"ordinary" users have.  In that case, _if_ a conversion happens, the
version number in the file will reflect a stable version, 2.12.0,
2.14.0, 2.16.0, 2.18.0: whatever is the oldest stable version left
unchanged by convert-ly.

Description:
Make convert-ly -d only ever update on changed files

Previously, it updated unconditionally whenever a new stable version
came out, leading to merge conflicts.  When the final applied
conversion is to an unstable version and the following stable version
is not beyond the conversion target, the following stable version is
used.

Note that this rule does not make a factual difference for continuous
updates of a code base (the normal use case for
scripts/auxiliar/update-with-convert-ly.sh), but it makes a difference
for the conversion/import of code that may have fallen behind a lot
(like with the LSR import, or when converting archived files).

Please review this at https://codereview.appspot.com/31830043/

Affected files (+15, -11 lines):
  M Documentation/usage/updating.itely
  M scripts/convert-ly.py


Index: Documentation/usage/updating.itely
diff --git a/Documentation/usage/updating.itely  
b/Documentation/usage/updating.itely
index  
06a960ac8a866faff27da9fece4208a96d395a78..ad92a834e35db8307521379f9dc4bd9789e6ce09  
100644
--- a/Documentation/usage/updating.itely
+++ b/Documentation/usage/updating.itely
@@ -151,8 +151,11 @@ The following options can be given:
 @item -d, --diff-version-update
 increase the @code{\version} string only if the file has actually
 been changed.  In that case, the version header will correspond to
-the version after the last actual change.  Without that option,
-the version will reflect the last @emph{attempted} conversion.
+the version after the last actual change.  An unstable version
+number will be rounded up to the next stable version number unless
+that would exceed the target version number.  Without this option,
+the version will instead reflect the last @emph{attempted}
+conversion.

 @item -e, --edit
 Apply the conversions direct to the input file, modifying it
Index: scripts/convert-ly.py
diff --git a/scripts/convert-ly.py b/scripts/convert-ly.py
index  
641d763713c979c06dfe0621e19959303765403d..ede9d4a98b81ea7309288364603c2a767cdca00a  
100644
--- a/scripts/convert-ly.py
+++ b/scripts/convert-ly.py
@@ -292,17 +292,18 @@ def do_one_file (infile_name):
             # Note that last_change can be set even if the result is
             # the same if two conversion rules cancelled out
             if result == input:
-                # check the y in x.y.z  (minor version number)
-                previous_stable = (last[0], 2*(last[1]/2), 0)
-                if ((last[0:2] != from_version[0:2]) and
-                    (previous_stable > from_version)):
-                    # previous stable version
-                    last = previous_stable
-                else:
-                    # make no (actual) change to the version number
-                    last = from_version
+                # make no (actual) change to the version number
+                last = from_version
             else:
                 last = last_change
+                # If the last update was to an unstable version
+                # number, and the final update target is no longer in
+                # the same unstable series, we update to the stable
+                # series following the unstable version.
+                if last[1]%2: # unstable
+                    next_stable = (last[0], last[1]+1, 0)
+                    if next_stable <= to_version:
+                        last = next_stable

         newversion = r'\version "%s"' % tup_to_str (last)
         if lilypond_version_re.search (result):