* incorrect working revision for the mercurial VC backend
@ 2009-12-30 1:53 Alex Harsanyi
2009-12-30 2:31 ` Nick Roberts
2009-12-30 3:29 ` Dan Nicolaescu
0 siblings, 2 replies; 8+ messages in thread
From: Alex Harsanyi @ 2009-12-30 1:53 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* incorrect working revision for the mercurial VC backend
2009-12-30 1:53 incorrect working revision for the mercurial VC backend Alex Harsanyi
@ 2009-12-30 2:31 ` Nick Roberts
[not found] ` <cf628bc60912291930x46faaa61j488e15cc5b953689@mail.gmail.com>
2009-12-30 3:29 ` Dan Nicolaescu
1 sibling, 1 reply; 8+ messages in thread
From: Nick Roberts @ 2009-12-30 2:31 UTC (permalink / raw
To: Alex Harsanyi; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
2009-12-30 1:53 incorrect working revision for the mercurial VC backend Alex Harsanyi
2009-12-30 2:31 ` Nick Roberts
@ 2009-12-30 3:29 ` Dan Nicolaescu
1 sibling, 0 replies; 8+ messages in thread
From: Dan Nicolaescu @ 2009-12-30 3:29 UTC (permalink / raw
To: Alex Harsanyi; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
[not found] ` <cf628bc60912291930x46faaa61j488e15cc5b953689@mail.gmail.com>
@ 2009-12-30 3:42 ` Nick Roberts
2009-12-30 6:15 ` Alex Harsanyi
0 siblings, 1 reply; 8+ messages in thread
From: Nick Roberts @ 2009-12-30 3:42 UTC (permalink / raw
To: Alex Harsanyi; +Cc: emacs-devel
[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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
2009-12-30 3:42 ` Nick Roberts
@ 2009-12-30 6:15 ` Alex Harsanyi
2009-12-30 7:02 ` Nick Roberts
2009-12-30 8:02 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Alex Harsanyi @ 2009-12-30 6:15 UTC (permalink / raw
To: Nick Roberts; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
2009-12-30 6:15 ` Alex Harsanyi
@ 2009-12-30 7:02 ` Nick Roberts
2009-12-30 8:02 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Nick Roberts @ 2009-12-30 7:02 UTC (permalink / raw
To: Alex Harsanyi; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
2009-12-30 6:15 ` Alex Harsanyi
2009-12-30 7:02 ` Nick Roberts
@ 2009-12-30 8:02 ` Eli Zaretskii
2009-12-30 9:37 ` Alex Harsanyi
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2009-12-30 8:02 UTC (permalink / raw
To: Alex Harsanyi; +Cc: nickrob, emacs-devel
> 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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: incorrect working revision for the mercurial VC backend
2009-12-30 8:02 ` Eli Zaretskii
@ 2009-12-30 9:37 ` Alex Harsanyi
0 siblings, 0 replies; 8+ messages in thread
From: Alex Harsanyi @ 2009-12-30 9:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: nickrob, emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-12-30 9:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-30 1:53 incorrect working revision for the mercurial VC backend Alex Harsanyi
2009-12-30 2:31 ` Nick Roberts
[not found] ` <cf628bc60912291930x46faaa61j488e15cc5b953689@mail.gmail.com>
2009-12-30 3:42 ` Nick Roberts
2009-12-30 6:15 ` Alex Harsanyi
2009-12-30 7:02 ` Nick Roberts
2009-12-30 8:02 ` Eli Zaretskii
2009-12-30 9:37 ` Alex Harsanyi
2009-12-30 3:29 ` Dan Nicolaescu
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.