incorrect working revision for the mercurial VC backend

incorrect working revision for the mercurial VC backend

[Alex Harsanyi]

It seems that `vc-hg-working-revision` is using "hg log -l1 FILE" to
obtain the working revision of the file.  This only works correctly if
the file is at the most recent revision in the workspace.  If you
update the workspace to a different repository revision using "hg
update -r REV", emacs will continue to think that files are at their
latest revision.  As a side effect, `vc-annotate` will always annotate
the latest revision of a file regardless of what the file revision is
in the workspace.

I believe using the "hg parent" command is more accurate in computing
the working revision:

    hg parent --template "{rev}" FILE

Also by using the --template option, the command will return just the
revision number, making the `string-match' call unnecessary.

Cheers,
Alex.

incorrect working revision for the mercurial VC backend

[Nick Roberts]

 > I believe using the "hg parent" command is more accurate in computing
 > the working revision:
 > 
 >     hg parent --template "{rev}" FILE
 > 
 > Also by using the --template option, the command will return just the
 > revision number, making the `string-match' call unnecessary.

To get some practice with bzr, I've pushed the change below.  Can you please
tell me if it DTRT for you?

-- 
Nick                                           http://users.snap.net.nz/~nickrob


2009-12-30  Nick Roberts  <nickrob@snap.net.nz>

	Show working revision correctly for mercurial.
	* vc-hg.el (vc-hg-working-revision): Use hg parent instead of
	hg log as suggested by Alex Harsanyi <alexharsanyi@gmail.com>,


=== modified file 'lisp/vc-hg.el'
*** lisp/vc-hg.el	2009-12-14 17:12:18 +0000
--- lisp/vc-hg.el	2009-12-30 02:22:45 +0000
*************** If nil, use the value of `vc-diff-switch
*** 209,222 ****
  			;; Ignore all errors.
  			(process-file
  			 "hg" nil t nil
! 			 "log" "-l1" (file-relative-name file)))
                      ;; Some problem happened.  E.g. We can't find an `hg'
                      ;; executable.
                      (error nil)))))))
!     (when (eq 0 status)
!       (if (string-match "changeset: *\\([0-9]*\\)" out)
!           (match-string 1 out)
!         "0"))))
  
  ;;; History functions
  
--- 209,219 ----
  			;; Ignore all errors.
  			(process-file
  			 "hg" nil t nil
! 			 "parent" "--template" "\"{rev}\"" (file-relative-name file)))
                      ;; Some problem happened.  E.g. We can't find an `hg'
                      ;; executable.
                      (error nil)))))))
!     (when (eq 0 status) (read out))))
  
  ;;; History functions
  

Re: incorrect working revision for the mercurial VC backend

[Nick Roberts]

[please cc the mailing list]

 > I haven't switched yet to bzr, so I cannot pull the change, however
 > the patch corresponds to my local fix, except that the last line
 > reads:

But you could apply the patch to your working copy.

 > (if (eq 0 status) out  "0")
 > 
 > This corresponds to the previous behavior of returning a string as the
 > revision and returning "0" if there is a problem with running the hg
 > command.

Does that really correspond to the previous behavior?

    ...
    (when (eq 0 status)
      (if (string-match "changeset: *\\([0-9]*\\)" out)
          (match-string 1 out)
        "0"))))

It returns "0" when there is no match but nil if status doesn't equal 0:

  when is a Lisp macro in `subr.el'.
  (when COND BODY...)

  If COND yields non-nil, do BODY, else return nil.

Also, iget a quoted string, e.g. "\"290\"", which is why I used read.


-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: incorrect working revision for the mercurial VC backend

[Alex Harsanyi]

On Wed, Dec 30, 2009 at 11:42 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
> [please cc the mailing list]
>
>  > I haven't switched yet to bzr, so I cannot pull the change, however
>  > the patch corresponds to my local fix, except that the last line
>  > reads:
>
> But you could apply the patch to your working copy.

I could not apply it. If I copy-paste it out of the email, patch rejects it:

$ patch -p1 < vc-hg.patch
patching file vc-hg.el
Hunk #1 FAILED at 209.
1 out of 1 hunk FAILED -- saving rejects to file vc-hg.el.rej

When I try to apply it from Emacs, it asks me first if I want to fix
word-wrap damage, but after I say yes, it fails anyway... Sorry but
I'm not sure what is wrong.

>
>  > (if (eq 0 status) out  "0")
>  >
>  > This corresponds to the previous behavior of returning a string as the
>  > revision and returning "0" if there is a problem with running the hg
>  > command.
>
> Does that really correspond to the previous behavior?
>
>    ...
>    (when (eq 0 status)
>      (if (string-match "changeset: *\\([0-9]*\\)" out)
>          (match-string 1 out)
>        "0"))))

You are right.

>
> Also, iget a quoted string, e.g. "\"290\"", which is why I used read.

This is because you use "\"{rev}\"" as the template instead of
"{rev}".    I used "{rev}" and I get just the revision e.g. 290.

Cheers,
Alex.

Re: incorrect working revision for the mercurial VC backend

[Nick Roberts]

 > I could not apply it. If I copy-paste it out of the email, patch rejects it:
 > 
 > $ patch -p1 < vc-hg.patch
 > patching file vc-hg.el
 > Hunk #1 FAILED at 209.
 > 1 out of 1 hunk FAILED -- saving rejects to file vc-hg.el.rej

I'm not sure how old your version of vc-hg.el is but it's a small patch which
could probaly be easily applied manually.  It's no big deal in this case but
generally it would be good if you could switch to bzr so that you know your
reports are against up-to-date source.


 > > Also, iget a quoted string, e.g. "\"290\"", which is why I used read.
 > 
 > This is because you use "\"{rev}\"" as the template instead of
 > "{rev}".    I used "{rev}" and I get just the revision e.g. 290.

Doh!  I've committed a change accordingly.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: incorrect working revision for the mercurial VC backend

[Eli Zaretskii]

> Date: Wed, 30 Dec 2009 14:15:05 +0800
> From: Alex Harsanyi <alexharsanyi@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Wed, Dec 30, 2009 at 11:42 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
> > [please cc the mailing list]
> >
> >  > I haven't switched yet to bzr, so I cannot pull the change, however
> >  > the patch corresponds to my local fix, except that the last line
> >  > reads:
> >
> > But you could apply the patch to your working copy.
> 
> I could not apply it. If I copy-paste it out of the email, patch rejects it:
> 
> $ patch -p1 < vc-hg.patch
> patching file vc-hg.el
> Hunk #1 FAILED at 209.
> 1 out of 1 hunk FAILED -- saving rejects to file vc-hg.el.rej
> 
> When I try to apply it from Emacs, it asks me first if I want to fix
> word-wrap damage, but after I say yes, it fails anyway... Sorry but
> I'm not sure what is wrong.

Perhaps try "patch --ignore-whitespace".

Re: incorrect working revision for the mercurial VC backend

[Alex Harsanyi]

On Wed, Dec 30, 2009 at 4:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 30 Dec 2009 14:15:05 +0800
>> From: Alex Harsanyi <alexharsanyi@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> On Wed, Dec 30, 2009 at 11:42 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
>> > [please cc the mailing list]
>> >
>> >  > I haven't switched yet to bzr, so I cannot pull the change, however
>> >  > the patch corresponds to my local fix, except that the last line
>> >  > reads:
>> >
>> > But you could apply the patch to your working copy.
>>
>> I could not apply it. If I copy-paste it out of the email, patch rejects it:
>>
>> $ patch -p1 < vc-hg.patch
>> patching file vc-hg.el
>> Hunk #1 FAILED at 209.
>> 1 out of 1 hunk FAILED -- saving rejects to file vc-hg.el.rej
>>
>> When I try to apply it from Emacs, it asks me first if I want to fix
>> word-wrap damage, but after I say yes, it fails anyway... Sorry but
>> I'm not sure what is wrong.
>
> Perhaps try "patch --ignore-whitespace".
>

That worked, thanks.

BTW, I did use the latest CVS version, and I do plan to switch to bzr,
except I will only have the time in a few weeks time

Cheers,
Alex.

Re: incorrect working revision for the mercurial VC backend

[Dan Nicolaescu]

Alex Harsanyi <alexharsanyi@gmail.com> writes:

  > It seems that `vc-hg-working-revision` is using "hg log -l1 FILE" to
  > obtain the working revision of the file.  This only works correctly if
  > the file is at the most recent revision in the workspace.  If you
  > update the workspace to a different repository revision using "hg
  > update -r REV", emacs will continue to think that files are at their
  > latest revision.  As a side effect, `vc-annotate` will always annotate
  > the latest revision of a file regardless of what the file revision is
  > in the workspace.
  > 
  > I believe using the "hg parent" command is more accurate in computing
  > the working revision:
  > 
  >     hg parent --template "{rev}" FILE
  > 
  > Also by using the --template option, the command will return just the
  > revision number, making the `string-match' call unnecessary.

Yes, see the recent discussion on the list, using "hg parent" is the
advice I got from Matt Mackall.  I'll make that change when I get a
chance.