bug#6968: 23.1; vc-hg-next-version fails if a custom style is used

bug#6968: 23.1; vc-hg-next-version fails if a custom style is used

[Kirk Kelsey]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

I've run into a problem with vc-hg-next-version and how it
identifies the maximum valid revision (the tip). Mercurial allows
for a templating of output for some commands, but
vc-hg-next-version identifies the tip using a regular expression
that only matches the "default" output style.

The patch below works by specifying the style explicitly.
Something similar is done for vc-hg-revision-table, where the
template for the log command is specified. FWIW, I took at look
at the other uses of vc-hg-command and didn't see any other cases
where the style seemed relevant. It is possible to work around
the issue by setting vc-hg-global-switches to include "--config
ui.style=default" (not using the --style option).



Thanks,
Kirk


--- /tmp/vc-hg.el       2010-09-01 16:48:56.000000000 -0400
+++ /tmp/vc-hg.fixed.el 2010-09-01 16:50:18.597813591 -0400
@@ -354,7 +354,7 @@
   (let ((newrev (1+ (string-to-number rev)))
         (tip-revision
          (with-temp-buffer
-           (vc-hg-command t 0 nil "tip")
+           (vc-hg-command t 0 nil "tip" "--style=default")
            (goto-char (point-min))
            (re-search-forward "^changeset:[ \t]*\\([0-9]+\\):")
            (string-to-number (match-string-no-properties 1)))))

[-- Attachment #2: Type: text/html, Size: 1680 bytes --]

bug#6968: 23.1; vc-hg-next-version fails if a custom style is used

[Kirk Kelsey]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

Well, I missed at least one other case where this can be a
problem. In vc-hg-working-revision, vc-hg-command isn't used.
In that case, the log output may be wrong, leading to failed
version identification. The work-around doesn't apply.

[-- Attachment #2: Type: text/html, Size: 304 bytes --]

bug#6968: 23.1; vc-hg-next-version fails if a custom style is used

[Glenn Morris]

Version: 24.3

Sorry for the horrendous delay; change applied to trunk. Thanks.

Kirk Kelsey wrote:

> Well, I missed at least one other case where this can be a
> problem. In vc-hg-working-revision, vc-hg-command isn't used.

Looks like this was independently changed in the meantime.