C-x v i bug

C-x v i bug

[Neal Becker]

hg status test_front_end_spec.py
*** failed to import extension rdiff: No module named rdiff
? test_front_end_spec.py

The above warning confuses emacs.  C-x v i report 'already registered'.

After I fixed the above warning (removed rdiff from my .hgrc), then C-x 
v i worked correctly.

Re: C-x v i bug

[Dan Nicolaescu]

Neal Becker <ndbecker2@gmail.com> writes:

  > hg status test_front_end_spec.py
  > *** failed to import extension rdiff: No module named rdiff
  > ? test_front_end_spec.py
  > 
  > The above warning confuses emacs.  C-x v i report 'already registered'.

Indeed, vc-hg-status parses the result of "hg status test_front_end_spec.py"

Is there are way to tell hg to ignore .hgrc ?  I.E. something like emacs -q ?

  > After I fixed the above warning (removed rdiff from my .hgrc), then C-x 
  > v i worked correctly.

Re: C-x v i bug

[Neal Becker]

Dan Nicolaescu wrote:

> Neal Becker <ndbecker2@gmail.com> writes:
> 
>   > hg status test_front_end_spec.py
>   > *** failed to import extension rdiff: No module named rdiff
>   > ? test_front_end_spec.py
>   > 
>   > The above warning confuses emacs.  C-x v i report 'already
>   > registered'.
> 
> Indeed, vc-hg-status parses the result of "hg status
> test_front_end_spec.py"
> 
> Is there are way to tell hg to ignore .hgrc ?  I.E. something like 
emacs
> -q ?
> 
>   > After I fixed the above warning (removed rdiff from my .hgrc), 
then
>   > C-x v i worked correctly.

HGRCPATH= hg showconfig

Re: C-x v i bug

[Dan Nicolaescu]

Neal Becker <ndbecker2@gmail.com> writes:

  > Dan Nicolaescu wrote:
  > 
  > > Neal Becker <ndbecker2@gmail.com> writes:
  > > 
  > >   > hg status test_front_end_spec.py
  > >   > *** failed to import extension rdiff: No module named rdiff
  > >   > ? test_front_end_spec.py
  > >   > 
  > >   > The above warning confuses emacs.  C-x v i report 'already
  > >   > registered'.
  > > 
  > > Indeed, vc-hg-status parses the result of "hg status
  > > test_front_end_spec.py"
  > > 
  > > Is there are way to tell hg to ignore .hgrc ?  I.E. something like 
  > emacs
  > > -q ?
  > > 
  > >   > After I fixed the above warning (removed rdiff from my .hgrc), 
  > then
  > >   > C-x v i worked correctly.
  > 
  > HGRCPATH= hg showconfig

So should we run HGRCPATH= hg status by default in vc-hg-state?

If yes, where else should we do it?

Re: C-x v i bug

[Neal Becker]

Dan Nicolaescu wrote:

> Neal Becker <ndbecker2@gmail.com> writes:
> 
>   > Dan Nicolaescu wrote:
>   > 
>   > > Neal Becker <ndbecker2@gmail.com> writes:
>   > > 
>   > >   > hg status test_front_end_spec.py
>   > >   > *** failed to import extension rdiff: No module named 
rdiff
>   > >   > ? test_front_end_spec.py
>   > >   > 
>   > >   > The above warning confuses emacs.  C-x v i report 'already
>   > >   > registered'.
>   > > 
>   > > Indeed, vc-hg-status parses the result of "hg status
>   > > test_front_end_spec.py"
>   > > 
>   > > Is there are way to tell hg to ignore .hgrc ?  I.E. something 
like
>   > emacs
>   > > -q ?
>   > > 
>   > >   > After I fixed the above warning (removed rdiff from my 
.hgrc),
>   > then
>   > >   > C-x v i worked correctly.
>   > 
>   > HGRCPATH= hg showconfig
> 
> So should we run HGRCPATH= hg status by default in vc-hg-state?
> 
> If yes, where else should we do it?

Crossposting to mercurial devel.  Anyone have suggestions?  My gut 
reaction is to say always use HGRCPATH='', but not really sure.

Re: C-x v i bug

[Stefan Monnier]

>> >   > hg status test_front_end_spec.py
>> >   > *** failed to import extension rdiff: No module named rdiff
>> >   > ? test_front_end_spec.py
>> >   > The above warning confuses emacs.  C-x v i report 'already
>> >   > registered'.
>> > Indeed, vc-hg-status parses the result of "hg status
>> > test_front_end_spec.py"
>> > Is there are way to tell hg to ignore .hgrc ?  I.E. something like
>> > emacs -q ?
>> >   > After I fixed the above warning (removed rdiff from my .hgrc),
>> >   > then C-x v i worked correctly.
>> HGRCPATH= hg showconfig
> So should we run HGRCPATH= hg status by default in vc-hg-state?

I haven't used Hg and don't know what you can put in .hgrc, so maybe I'm
way off base, but at least for Bazaar and CVS I think it would be wrong
to ignore the user's .cvsrc and .bazaar/bazaar.conf.


        Stefan

Re: C-x v i bug

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> >   > hg status test_front_end_spec.py
  > >> >   > *** failed to import extension rdiff: No module named rdiff
  > >> >   > ? test_front_end_spec.py
  > >> >   > The above warning confuses emacs.  C-x v i report 'already
  > >> >   > registered'.
  > >> > Indeed, vc-hg-status parses the result of "hg status
  > >> > test_front_end_spec.py"
  > >> > Is there are way to tell hg to ignore .hgrc ?  I.E. something like
  > >> > emacs -q ?
  > >> >   > After I fixed the above warning (removed rdiff from my .hgrc),
  > >> >   > then C-x v i worked correctly.
  > >> HGRCPATH= hg showconfig
  > > So should we run HGRCPATH= hg status by default in vc-hg-state?
  > 
  > I haven't used Hg and don't know what you can put in .hgrc, so maybe I'm
  > way off base, but at least for Bazaar and CVS I think it would be wrong
  > to ignore the user's .cvsrc and .bazaar/bazaar.conf.

At least for vc-hg-state using HGRCPATH= is justfied:
1. vc-hg-state needs to be very fast, so not having to initialize
plugins should help.
2. the return value should not depend on whatever the user puts in .hgrc
(I think, I've never written a .hgrc file, so...)

Re: C-x v i bug

[Martin Geisler]

[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]

Neal Becker <ndbecker2@gmail.com> writes:

> Dan Nicolaescu wrote:
>
>> Neal Becker <ndbecker2@gmail.com> writes:
>> 
>>   > Dan Nicolaescu wrote:
>>   > 
>>   > > Neal Becker <ndbecker2@gmail.com> writes:
>>   > > 
>>   > >   > hg status test_front_end_spec.py
>>   > >   > *** failed to import extension rdiff: No module named 
> rdiff
>>   > >   > ? test_front_end_spec.py
>>   > >   > 
>>   > >   > The above warning confuses emacs.  C-x v i report 'already
>>   > >   > registered'.
>>   > > 
>>   > > Indeed, vc-hg-status parses the result of "hg status
>>   > > test_front_end_spec.py"
>>   > > 
>>   > > Is there are way to tell hg to ignore .hgrc ?  I.E. something 
> like
>>   > emacs
>>   > > -q ?
>>   > > 
>>   > >   > After I fixed the above warning (removed rdiff from my 
> .hgrc),
>>   > then
>>   > >   > C-x v i worked correctly.
>>   > 
>>   > HGRCPATH= hg showconfig
>> 
>> So should we run HGRCPATH= hg status by default in vc-hg-state?
>> 
>> If yes, where else should we do it?
>
> Crossposting to mercurial devel.  Anyone have suggestions?  My gut 
> reaction is to say always use HGRCPATH='', but not really sure.

That will indeed turn off customizations in ~/.hgrc. But the user will
also lose the ui.username setting which might not be what you want when
you make a commit :-)

Brodie Rao has been working on an a patch that will allow you to set
HGPLAIN to make Mercurial revert to 'plain' behavior:

  http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode

It will disable localization and reset verbose mode.

However, it will not help you here: the user has mis-configured
Mercurial by asking it to load an extension that does not exist. The
warning will still be issued with Brodie's HGPLAIN patch.

I think the best solution is to teach your mode to ignore these warnings
From Mercurial.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

Re: C-x v i bug

[Brodie Rao]

On Dec 3, 2009, at 6:01 PM, Martin Geisler wrote:

> Neal Becker <ndbecker2@gmail.com> writes:

[snip]

>> Crossposting to mercurial devel.  Anyone have suggestions?  My gut 
>> reaction is to say always use HGRCPATH='', but not really sure.
> 
> That will indeed turn off customizations in ~/.hgrc. But the user will
> also lose the ui.username setting which might not be what you want when
> you make a commit :-)
> 
> Brodie Rao has been working on an a patch that will allow you to set
> HGPLAIN to make Mercurial revert to 'plain' behavior:
> 
>  http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode

This patch is still highly experimental. There are some things I need to rework, and it's not really a solution you can use right now because it's against hg itself.

Setting HGRCPATH= is one option, but as Martin mentioned, you'll lose all user configuration: their username, ssh settings, diff options, merge settings, enabled extensions, etc.

Another option is to run all commands like this:

hg --config ui.debug=0 --config ui.quiet=0 --config ui.verbose=0 --config defaults.CMD= CMD

You'll also want to set LANG=C and possibly deal with other LC_* envvars. For stderr output, perhaps diverting it to a buffer and ignoring it would be best. That particular extension warning won't change the return code of any command, which I assume is getting checked.

Re: C-x v i bug

[Dan Nicolaescu]

Brodie Rao <dackze@gmail.com> writes:

  > On Dec 3, 2009, at 6:01 PM, Martin Geisler wrote:
  > 
  > > Neal Becker <ndbecker2@gmail.com> writes:
  > 
  > [snip]
  > 
  > >> Crossposting to mercurial devel.  Anyone have suggestions?  My gut 
  > >> reaction is to say always use HGRCPATH='', but not really sure.
  > > 
  > > That will indeed turn off customizations in ~/.hgrc. But the user will
  > > also lose the ui.username setting which might not be what you want when
  > > you make a commit :-)
  > > 
  > > Brodie Rao has been working on an a patch that will allow you to set
  > > HGPLAIN to make Mercurial revert to 'plain' behavior:
  > > 
  > >  http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode
  > 
  > This patch is still highly experimental. There are some things I need to rework, and it's not really a solution you can use right now because it's against hg itself.
  > 
  > Setting HGRCPATH= is one option, but as Martin mentioned, you'll lose all user configuration: their username, ssh settings, diff options, merge settings, enabled extensions, etc.
  > 
  > Another option is to run all commands like this:
  > 
  > hg --config ui.debug=0 --config ui.quiet=0 --config ui.verbose=0 --config defaults.CMD= CMD

Let's first talk about the original problem that started this
discussion.
When a file in a directory that is under mercurial control is opened in
emacs, emacs runs "hg status FILE" so that it knows if it's registered
or not, if it's modified, etc.  
Any user settings in .hgrc should be irrelevant to the above.  Right?
It's desirable that this is as fast as possible, so processing .hgrc,
initializing plugins will just waste time.
After that emacs will want to know the version number for the file, for that
it runs "hg log -l1 FILE", and parse it from the output.
Any user settings in .hgrc should be irrelevant for this command.  Right?

[too bad that the status and version number are not available from a
single command...]

Re: C-x v i bug

[Martin Geisler]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Let's first talk about the original problem that started this
> discussion.
>
> When a file in a directory that is under mercurial control is opened
> in emacs, emacs runs "hg status FILE" so that it knows if it's
> registered or not, if it's modified, etc.
>
> Any user settings in .hgrc should be irrelevant to the above. Right?

Right. Many people use the color extension to get better feedback from
'hg status', but if Emacs sets TERM=dumb, then the extension will
disable itself. I'm just mentioning color to say that there are useful
extensions out there that modify even basic commands like 'hg status'.

> It's desirable that this is as fast as possible, so processing .hgrc,
> initializing plugins will just waste time.
> After that emacs will want to know the version number for the file, for that
> it runs "hg log -l1 FILE", and parse it from the output.
> Any user settings in .hgrc should be irrelevant for this command.  Right?

Right, and it's even quite important that you disable localization (run
hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:

  % hg log -l1 README
  ændring:     9586:a41f2840f9c6
  bruger:      Lee Cantey <lcantey@gmail.com>
  dato:        Tue Oct 13 12:27:50 2009 -0700
  uddrag:      README: revert accidental commit

The user could also very well have installed a different default style
by setting ui.style. On the command line it's done line this:

  % hg log -l1 README --style=compact
  9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
    README: revert accidental commit

> [too bad that the status and version number are not available from a
> single command...]

Well, you know, files don't really have a version number with modern
version control systems. The entire tree has a version number... You can
of course ask about when a file was last touched, but I think that
information is getting more and more irrelevant these days.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.

Re: C-x v i bug

[Dan Nicolaescu]

Martin Geisler <mg@lazybytes.net> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Let's first talk about the original problem that started this
  > > discussion.
  > >
  > > When a file in a directory that is under mercurial control is opened
  > > in emacs, emacs runs "hg status FILE" so that it knows if it's
  > > registered or not, if it's modified, etc.
  > >
  > > Any user settings in .hgrc should be irrelevant to the above. Right?
  > 
  > Right. Many people use the color extension to get better feedback from
  > 'hg status', but if Emacs sets TERM=dumb, then the extension will
  > disable itself. I'm just mentioning color to say that there are useful
  > extensions out there that modify even basic commands like 'hg status'.
  > 
  > > It's desirable that this is as fast as possible, so processing .hgrc,
  > > initializing plugins will just waste time.
  > > After that emacs will want to know the version number for the file, for that
  > > it runs "hg log -l1 FILE", and parse it from the output.
  > > Any user settings in .hgrc should be irrelevant for this command.  Right?
  > 
  > Right, and it's even quite important that you disable localization (run
  > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
  > 
  >   % hg log -l1 README
  >   ændring:     9586:a41f2840f9c6
  >   bruger:      Lee Cantey <lcantey@gmail.com>
  >   dato:        Tue Oct 13 12:27:50 2009 -0700
  >   uddrag:      README: revert accidental commit
  > 
  > The user could also very well have installed a different default style
  > by setting ui.style. On the command line it's done line this:

Thank you, this was very useful in taking care of some issues in emacs.

  >   % hg log -l1 README --style=compact
  >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
  >     README: revert accidental commit
  > 
  > > [too bad that the status and version number are not available from a
  > > single command...]
  > 
  > Well, you know, files don't really have a version number with modern
  > version control systems. The entire tree has a version number... You can
  > of course ask about when a file was last touched, but I think that
  > information is getting more and more irrelevant these days.

In emacs the generic Version Control layer needs a version number in some case.
Here's an example from a bug report:

cd  /tmp
mkdir hgtest2
cd hgtest2
hg init
echo foo > foo.txt
hg add foo.txt
hg commit -m "Added foo.txt"
hg branch bar
echo bar > foo.txt
hg commit -m "Changed foo to bar"
hg update -r default
echo frobozz > frobozz.txt
hg add frobozz.txt
hg commit -m "Added frobozz.txt"


now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
annotated version, emacs does that by running

hg annotate -r REVISION foo.txt

How can REVISION be obtained in this case?
It should be "0", but
hg log -l1 foo.txt
does not show that...

Thanks!
  

Re: C-x v i bug

[Matt Mackall]

On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
> Martin Geisler <mg@lazybytes.net> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > Let's first talk about the original problem that started this
>   > > discussion.
>   > >
>   > > When a file in a directory that is under mercurial control is opened
>   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
>   > > registered or not, if it's modified, etc.
>   > >
>   > > Any user settings in .hgrc should be irrelevant to the above. Right?
>   > 
>   > Right. Many people use the color extension to get better feedback from
>   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
>   > disable itself. I'm just mentioning color to say that there are useful
>   > extensions out there that modify even basic commands like 'hg status'.
>   > 
>   > > It's desirable that this is as fast as possible, so processing .hgrc,
>   > > initializing plugins will just waste time.
>   > > After that emacs will want to know the version number for the file, for that
>   > > it runs "hg log -l1 FILE", and parse it from the output.
>   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
>   > 
>   > Right, and it's even quite important that you disable localization (run
>   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
>   > 
>   >   % hg log -l1 README
>   >   ændring:     9586:a41f2840f9c6
>   >   bruger:      Lee Cantey <lcantey@gmail.com>
>   >   dato:        Tue Oct 13 12:27:50 2009 -0700
>   >   uddrag:      README: revert accidental commit
>   > 
>   > The user could also very well have installed a different default style
>   > by setting ui.style. On the command line it's done line this:
> 
> Thank you, this was very useful in taking care of some issues in emacs.
> 
>   >   % hg log -l1 README --style=compact
>   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
>   >     README: revert accidental commit
>   > 
>   > > [too bad that the status and version number are not available from a
>   > > single command...]
>   > 
>   > Well, you know, files don't really have a version number with modern
>   > version control systems. The entire tree has a version number... You can
>   > of course ask about when a file was last touched, but I think that
>   > information is getting more and more irrelevant these days.
> 
> In emacs the generic Version Control layer needs a version number in some case.
> Here's an example from a bug report:
> 
> cd  /tmp
> mkdir hgtest2
> cd hgtest2
> hg init
> echo foo > foo.txt
> hg add foo.txt
> hg commit -m "Added foo.txt"
> hg branch bar
> echo bar > foo.txt
> hg commit -m "Changed foo to bar"
> hg update -r default
> echo frobozz > frobozz.txt
> hg add frobozz.txt
> hg commit -m "Added frobozz.txt"
> 
> 
> now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
> annotated version, emacs does that by running
> 
> hg annotate -r REVISION foo.txt
>
> How can REVISION be obtained in this case?
> It should be "0", but
> hg log -l1 foo.txt
> does not show that...

Version numbers are not per-file in Mercurial. The number you should use
is the global number (or numbers!) reported by hg parents. This revision
is also known as '.', eg 'hg annotate -r . foo.txt'. 

You're probably thinking "but I actually want to report the last
changeset this file was touched in to be more like CVS". No, you don't,
that's not the Mercurial way. Trying to emulate CVS is doing your users
a disservice.

As a side note, if you want history relative to the working directory
(and not just all of history), you'll want the -f flag to log.

-- 
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Re: C-x v i bug

[Dan Nicolaescu]

Matt Mackall <mpm@selenic.com> writes:

  > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
  > > Martin Geisler <mg@lazybytes.net> writes:
  > > 
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > Let's first talk about the original problem that started this
  > >   > > discussion.
  > >   > >
  > >   > > When a file in a directory that is under mercurial control is opened
  > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
  > >   > > registered or not, if it's modified, etc.
  > >   > >
  > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
  > >   > 
  > >   > Right. Many people use the color extension to get better feedback from
  > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
  > >   > disable itself. I'm just mentioning color to say that there are useful
  > >   > extensions out there that modify even basic commands like 'hg status'.
  > >   > 
  > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
  > >   > > initializing plugins will just waste time.
  > >   > > After that emacs will want to know the version number for the file, for that
  > >   > > it runs "hg log -l1 FILE", and parse it from the output.
  > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
  > >   > 
  > >   > Right, and it's even quite important that you disable localization (run
  > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
  > >   > 
  > >   >   % hg log -l1 README
  > >   >   ændring:     9586:a41f2840f9c6
  > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
  > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
  > >   >   uddrag:      README: revert accidental commit
  > >   > 
  > >   > The user could also very well have installed a different default style
  > >   > by setting ui.style. On the command line it's done line this:
  > > 
  > > Thank you, this was very useful in taking care of some issues in emacs.
  > > 
  > >   >   % hg log -l1 README --style=compact
  > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
  > >   >     README: revert accidental commit
  > >   > 
  > >   > > [too bad that the status and version number are not available from a
  > >   > > single command...]
  > >   > 
  > >   > Well, you know, files don't really have a version number with modern
  > >   > version control systems. The entire tree has a version number... You can
  > >   > of course ask about when a file was last touched, but I think that
  > >   > information is getting more and more irrelevant these days.
  > > 
  > > In emacs the generic Version Control layer needs a version number in some case.
  > > Here's an example from a bug report:
  > > 
  > > cd  /tmp
  > > mkdir hgtest2
  > > cd hgtest2
  > > hg init
  > > echo foo > foo.txt
  > > hg add foo.txt
  > > hg commit -m "Added foo.txt"
  > > hg branch bar
  > > echo bar > foo.txt
  > > hg commit -m "Changed foo to bar"
  > > hg update -r default
  > > echo frobozz > frobozz.txt
  > > hg add frobozz.txt
  > > hg commit -m "Added frobozz.txt"
  > > 
  > > 
  > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
  > > annotated version, emacs does that by running
  > > 
  > > hg annotate -r REVISION foo.txt
  > >
  > > How can REVISION be obtained in this case?
  > > It should be "0", but
  > > hg log -l1 foo.txt
  > > does not show that...
  > 
  > Version numbers are not per-file in Mercurial. The number you should use
  > is the global number (or numbers!) reported by hg parents. This revision
  > is also known as '.', eg 'hg annotate -r . foo.txt'. 

. is not usable in all cases.   For the example above:

hg log -r . foo.txt 

does not work, it does not show anything.

But "hg parents foo.txt" parse VERSION from there

hg log -r VERSION foo.txt

works.

So it seems that getting the result of hg parents is TRTD.

  > You're probably thinking "but I actually want to report the last
  > changeset this file was touched in to be more like CVS". 

Nope, not at all.  Nothing is trying to be like CVS here.

  > As a side note, if you want history relative to the working directory
  > (and not just all of history), you'll want the -f flag to log.

What's the more useful version that gives the user a better idea what
happened to the file in question?
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Re: C-x v i bug

[Matt Mackall]

On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
>   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
>   > > Martin Geisler <mg@lazybytes.net> writes:
>   > > 
>   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > >   > 
>   > >   > > Let's first talk about the original problem that started this
>   > >   > > discussion.
>   > >   > >
>   > >   > > When a file in a directory that is under mercurial control is opened
>   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
>   > >   > > registered or not, if it's modified, etc.
>   > >   > >
>   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
>   > >   > 
>   > >   > Right. Many people use the color extension to get better feedback from
>   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
>   > >   > disable itself. I'm just mentioning color to say that there are useful
>   > >   > extensions out there that modify even basic commands like 'hg status'.
>   > >   > 
>   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
>   > >   > > initializing plugins will just waste time.
>   > >   > > After that emacs will want to know the version number for the file, for that
>   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
>   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
>   > >   > 
>   > >   > Right, and it's even quite important that you disable localization (run
>   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
>   > >   > 
>   > >   >   % hg log -l1 README
>   > >   >   ændring:     9586:a41f2840f9c6
>   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
>   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
>   > >   >   uddrag:      README: revert accidental commit
>   > >   > 
>   > >   > The user could also very well have installed a different default style
>   > >   > by setting ui.style. On the command line it's done line this:
>   > > 
>   > > Thank you, this was very useful in taking care of some issues in emacs.
>   > > 
>   > >   >   % hg log -l1 README --style=compact
>   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
>   > >   >     README: revert accidental commit
>   > >   > 
>   > >   > > [too bad that the status and version number are not available from a
>   > >   > > single command...]
>   > >   > 
>   > >   > Well, you know, files don't really have a version number with modern
>   > >   > version control systems. The entire tree has a version number... You can
>   > >   > of course ask about when a file was last touched, but I think that
>   > >   > information is getting more and more irrelevant these days.
>   > > 
>   > > In emacs the generic Version Control layer needs a version number in some case.
>   > > Here's an example from a bug report:
>   > > 
>   > > cd  /tmp
>   > > mkdir hgtest2
>   > > cd hgtest2
>   > > hg init
>   > > echo foo > foo.txt
>   > > hg add foo.txt
>   > > hg commit -m "Added foo.txt"
>   > > hg branch bar
>   > > echo bar > foo.txt
>   > > hg commit -m "Changed foo to bar"
>   > > hg update -r default
>   > > echo frobozz > frobozz.txt
>   > > hg add frobozz.txt
>   > > hg commit -m "Added frobozz.txt"
>   > > 
>   > > 
>   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
>   > > annotated version, emacs does that by running
>   > > 
>   > > hg annotate -r REVISION foo.txt
>   > >
>   > > How can REVISION be obtained in this case?
>   > > It should be "0", but
>   > > hg log -l1 foo.txt
>   > > does not show that...
>   > 
>   > Version numbers are not per-file in Mercurial. The number you should use
>   > is the global number (or numbers!) reported by hg parents. This revision
>   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
> 
> . is not usable in all cases.   For the example above:
> 
> hg log -r . foo.txt 
> 
> does not work, it does not show anything.

I just tested it with the above commands and it works at least as far
back as 1.0.

> works.
> 
> So it seems that getting the result of hg parents is TRTD.
> 
>   > You're probably thinking "but I actually want to report the last
>   > changeset this file was touched in to be more like CVS". 
> 
> Nope, not at all.  Nothing is trying to be like CVS here.
> 
>   > As a side note, if you want history relative to the working directory
>   > (and not just all of history), you'll want the -f flag to log.
> 
> What's the more useful version that gives the user a better idea what
> happened to the file in question?

Depends.

-- 
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Re: C-x v i bug

[Dan Nicolaescu]

Matt Mackall <mpm@selenic.com> writes:

  > On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
  > > Matt Mackall <mpm@selenic.com> writes:
  > > 
  > >   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
  > >   > > Martin Geisler <mg@lazybytes.net> writes:
  > >   > > 
  > >   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > >   > 
  > >   > >   > > Let's first talk about the original problem that started this
  > >   > >   > > discussion.
  > >   > >   > >
  > >   > >   > > When a file in a directory that is under mercurial control is opened
  > >   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
  > >   > >   > > registered or not, if it's modified, etc.
  > >   > >   > >
  > >   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
  > >   > >   > 
  > >   > >   > Right. Many people use the color extension to get better feedback from
  > >   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
  > >   > >   > disable itself. I'm just mentioning color to say that there are useful
  > >   > >   > extensions out there that modify even basic commands like 'hg status'.
  > >   > >   > 
  > >   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
  > >   > >   > > initializing plugins will just waste time.
  > >   > >   > > After that emacs will want to know the version number for the file, for that
  > >   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
  > >   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
  > >   > >   > 
  > >   > >   > Right, and it's even quite important that you disable localization (run
  > >   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
  > >   > >   > 
  > >   > >   >   % hg log -l1 README
  > >   > >   >   ændring:     9586:a41f2840f9c6
  > >   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
  > >   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
  > >   > >   >   uddrag:      README: revert accidental commit
  > >   > >   > 
  > >   > >   > The user could also very well have installed a different default style
  > >   > >   > by setting ui.style. On the command line it's done line this:
  > >   > > 
  > >   > > Thank you, this was very useful in taking care of some issues in emacs.
  > >   > > 
  > >   > >   >   % hg log -l1 README --style=compact
  > >   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
  > >   > >   >     README: revert accidental commit
  > >   > >   > 
  > >   > >   > > [too bad that the status and version number are not available from a
  > >   > >   > > single command...]
  > >   > >   > 
  > >   > >   > Well, you know, files don't really have a version number with modern
  > >   > >   > version control systems. The entire tree has a version number... You can
  > >   > >   > of course ask about when a file was last touched, but I think that
  > >   > >   > information is getting more and more irrelevant these days.
  > >   > > 
  > >   > > In emacs the generic Version Control layer needs a version number in some case.
  > >   > > Here's an example from a bug report:
  > >   > > 
  > >   > > cd  /tmp
  > >   > > mkdir hgtest2
  > >   > > cd hgtest2
  > >   > > hg init
  > >   > > echo foo > foo.txt
  > >   > > hg add foo.txt
  > >   > > hg commit -m "Added foo.txt"
  > >   > > hg branch bar
  > >   > > echo bar > foo.txt
  > >   > > hg commit -m "Changed foo to bar"
  > >   > > hg update -r default
  > >   > > echo frobozz > frobozz.txt
  > >   > > hg add frobozz.txt
  > >   > > hg commit -m "Added frobozz.txt"
  > >   > > 
  > >   > > 
  > >   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
  > >   > > annotated version, emacs does that by running
  > >   > > 
  > >   > > hg annotate -r REVISION foo.txt
  > >   > >
  > >   > > How can REVISION be obtained in this case?
  > >   > > It should be "0", but
  > >   > > hg log -l1 foo.txt
  > >   > > does not show that...
  > >   > 
  > >   > Version numbers are not per-file in Mercurial. The number you should use
  > >   > is the global number (or numbers!) reported by hg parents. This revision
  > >   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
  > > 
  > > . is not usable in all cases.   For the example above:
  > > 
  > > hg log -r . foo.txt 
  > > 
  > > does not work, it does not show anything.
  > 
  > I just tested it with the above commands and it works at least as far
  > back as 1.0.

 cat foo.txt
foo
$ hg parents foo.txt 
changeset:   0:1ac3a9e3757e
user:        blah@blah.com
date:        Thu Dec 17 08:06:39 2009 -0800
summary:     Added foo.txt

$ hg log foo.txt 
changeset:   1:6d88f588d323
branch:      bar
user:        blah@blah.com
date:        Thu Dec 17 08:06:39 2009 -0800
summary:     Changed foo to bar

changeset:   0:1ac3a9e3757e
user:        blah@blah.com
date:        Thu Dec 17 08:06:39 2009 -0800
summary:     Added foo.txt

$ hg log -r . foo.txt 
$ env HGRC= hg log -r . foo.txt
$ hg --version
Mercurial Distributed SCM (version 1.4)

Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This is on an up to date Fedora 12 machine.

Is your output different.

Re: C-x v i bug

[Matt Mackall]

On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
>   > On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
>   > > Matt Mackall <mpm@selenic.com> writes:
>   > > 
>   > >   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
>   > >   > > Martin Geisler <mg@lazybytes.net> writes:
>   > >   > > 
>   > >   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > >   > >   > 
>   > >   > >   > > Let's first talk about the original problem that started this
>   > >   > >   > > discussion.
>   > >   > >   > >
>   > >   > >   > > When a file in a directory that is under mercurial control is opened
>   > >   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
>   > >   > >   > > registered or not, if it's modified, etc.
>   > >   > >   > >
>   > >   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
>   > >   > >   > 
>   > >   > >   > Right. Many people use the color extension to get better feedback from
>   > >   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
>   > >   > >   > disable itself. I'm just mentioning color to say that there are useful
>   > >   > >   > extensions out there that modify even basic commands like 'hg status'.
>   > >   > >   > 
>   > >   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
>   > >   > >   > > initializing plugins will just waste time.
>   > >   > >   > > After that emacs will want to know the version number for the file, for that
>   > >   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
>   > >   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
>   > >   > >   > 
>   > >   > >   > Right, and it's even quite important that you disable localization (run
>   > >   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
>   > >   > >   > 
>   > >   > >   >   % hg log -l1 README
>   > >   > >   >   ændring:     9586:a41f2840f9c6
>   > >   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
>   > >   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
>   > >   > >   >   uddrag:      README: revert accidental commit
>   > >   > >   > 
>   > >   > >   > The user could also very well have installed a different default style
>   > >   > >   > by setting ui.style. On the command line it's done line this:
>   > >   > > 
>   > >   > > Thank you, this was very useful in taking care of some issues in emacs.
>   > >   > > 
>   > >   > >   >   % hg log -l1 README --style=compact
>   > >   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
>   > >   > >   >     README: revert accidental commit
>   > >   > >   > 
>   > >   > >   > > [too bad that the status and version number are not available from a
>   > >   > >   > > single command...]
>   > >   > >   > 
>   > >   > >   > Well, you know, files don't really have a version number with modern
>   > >   > >   > version control systems. The entire tree has a version number... You can
>   > >   > >   > of course ask about when a file was last touched, but I think that
>   > >   > >   > information is getting more and more irrelevant these days.
>   > >   > > 
>   > >   > > In emacs the generic Version Control layer needs a version number in some case.
>   > >   > > Here's an example from a bug report:
>   > >   > > 
>   > >   > > cd  /tmp
>   > >   > > mkdir hgtest2
>   > >   > > cd hgtest2
>   > >   > > hg init
>   > >   > > echo foo > foo.txt
>   > >   > > hg add foo.txt
>   > >   > > hg commit -m "Added foo.txt"
>   > >   > > hg branch bar
>   > >   > > echo bar > foo.txt
>   > >   > > hg commit -m "Changed foo to bar"
>   > >   > > hg update -r default
>   > >   > > echo frobozz > frobozz.txt
>   > >   > > hg add frobozz.txt
>   > >   > > hg commit -m "Added frobozz.txt"
>   > >   > > 
>   > >   > > 
>   > >   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
>   > >   > > annotated version, emacs does that by running
>   > >   > > 
>   > >   > > hg annotate -r REVISION foo.txt
>   > >   > >
>   > >   > > How can REVISION be obtained in this case?
>   > >   > > It should be "0", but
>   > >   > > hg log -l1 foo.txt
>   > >   > > does not show that...
>   > >   > 
>   > >   > Version numbers are not per-file in Mercurial. The number you should use
>   > >   > is the global number (or numbers!) reported by hg parents. This revision
>   > >   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
>   > > 
>   > > . is not usable in all cases.   For the example above:
>   > > 
>   > > hg log -r . foo.txt 
>   > > 
>   > > does not work, it does not show anything.
>   > 
>   > I just tested it with the above commands and it works at least as far
>   > back as 1.0.
> 
>  cat foo.txt
> foo
> $ hg parents foo.txt 
> changeset:   0:1ac3a9e3757e
> user:        blah@blah.com
> date:        Thu Dec 17 08:06:39 2009 -0800
> summary:     Added foo.txt
> 
> $ hg log foo.txt 
> changeset:   1:6d88f588d323
> branch:      bar
> user:        blah@blah.com
> date:        Thu Dec 17 08:06:39 2009 -0800
> summary:     Changed foo to bar
> 
> changeset:   0:1ac3a9e3757e
> user:        blah@blah.com
> date:        Thu Dec 17 08:06:39 2009 -0800
> summary:     Added foo.txt
> 
> $ hg log -r . foo.txt 
> $ env HGRC= hg log -r . foo.txt

There's no such environment variable. Perhaps you want HGRCPATH.

> $ hg --version
> Mercurial Distributed SCM (version 1.4)
> 
> Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> This is on an up to date Fedora 12 machine.
> 
> Is your output different.

Yes. The following script:

#!/bin/sh

rm -rf a
hg init a
cd a

echo foo > foo.txt
hg add foo.txt
hg commit -qm "Added foo.txt"
hg branch -q bar
echo bar > foo.txt
hg commit -qm "Changed foo to bar"
hg update -qr default
echo frobozz > frobozz.txt
hg add frobozz.txt
hg commit -qm "Added frobozz.txt"
hg annotate -r . foo.txt

gives me:

0: foo

-- 
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Re: C-x v i bug

[Dan Nicolaescu]

Matt Mackall <mpm@selenic.com> writes:

  > On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote:
  > > Matt Mackall <mpm@selenic.com> writes:
  > > 
  > >   > On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
  > >   > > Matt Mackall <mpm@selenic.com> writes:
  > >   > > 
  > >   > >   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
  > >   > >   > > Martin Geisler <mg@lazybytes.net> writes:
  > >   > >   > > 
  > >   > >   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > >   > >   > 
  > >   > >   > >   > > Let's first talk about the original problem that started this
  > >   > >   > >   > > discussion.
  > >   > >   > >   > >
  > >   > >   > >   > > When a file in a directory that is under mercurial control is opened
  > >   > >   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
  > >   > >   > >   > > registered or not, if it's modified, etc.
  > >   > >   > >   > >
  > >   > >   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
  > >   > >   > >   > 
  > >   > >   > >   > Right. Many people use the color extension to get better feedback from
  > >   > >   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
  > >   > >   > >   > disable itself. I'm just mentioning color to say that there are useful
  > >   > >   > >   > extensions out there that modify even basic commands like 'hg status'.
  > >   > >   > >   > 
  > >   > >   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
  > >   > >   > >   > > initializing plugins will just waste time.
  > >   > >   > >   > > After that emacs will want to know the version number for the file, for that
  > >   > >   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
  > >   > >   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
  > >   > >   > >   > 
  > >   > >   > >   > Right, and it's even quite important that you disable localization (run
  > >   > >   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
  > >   > >   > >   > 
  > >   > >   > >   >   % hg log -l1 README
  > >   > >   > >   >   ændring:     9586:a41f2840f9c6
  > >   > >   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
  > >   > >   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
  > >   > >   > >   >   uddrag:      README: revert accidental commit
  > >   > >   > >   > 
  > >   > >   > >   > The user could also very well have installed a different default style
  > >   > >   > >   > by setting ui.style. On the command line it's done line this:
  > >   > >   > > 
  > >   > >   > > Thank you, this was very useful in taking care of some issues in emacs.
  > >   > >   > > 
  > >   > >   > >   >   % hg log -l1 README --style=compact
  > >   > >   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
  > >   > >   > >   >     README: revert accidental commit
  > >   > >   > >   > 
  > >   > >   > >   > > [too bad that the status and version number are not available from a
  > >   > >   > >   > > single command...]
  > >   > >   > >   > 
  > >   > >   > >   > Well, you know, files don't really have a version number with modern
  > >   > >   > >   > version control systems. The entire tree has a version number... You can
  > >   > >   > >   > of course ask about when a file was last touched, but I think that
  > >   > >   > >   > information is getting more and more irrelevant these days.
  > >   > >   > > 
  > >   > >   > > In emacs the generic Version Control layer needs a version number in some case.
  > >   > >   > > Here's an example from a bug report:
  > >   > >   > > 
  > >   > >   > > cd  /tmp
  > >   > >   > > mkdir hgtest2
  > >   > >   > > cd hgtest2
  > >   > >   > > hg init
  > >   > >   > > echo foo > foo.txt
  > >   > >   > > hg add foo.txt
  > >   > >   > > hg commit -m "Added foo.txt"
  > >   > >   > > hg branch bar
  > >   > >   > > echo bar > foo.txt
  > >   > >   > > hg commit -m "Changed foo to bar"
  > >   > >   > > hg update -r default
  > >   > >   > > echo frobozz > frobozz.txt
  > >   > >   > > hg add frobozz.txt
  > >   > >   > > hg commit -m "Added frobozz.txt"
  > >   > >   > > 
  > >   > >   > > 
  > >   > >   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
  > >   > >   > > annotated version, emacs does that by running
  > >   > >   > > 
  > >   > >   > > hg annotate -r REVISION foo.txt
  > >   > >   > >
  > >   > >   > > How can REVISION be obtained in this case?
  > >   > >   > > It should be "0", but
  > >   > >   > > hg log -l1 foo.txt
  > >   > >   > > does not show that...
  > >   > >   > 
  > >   > >   > Version numbers are not per-file in Mercurial. The number you should use
  > >   > >   > is the global number (or numbers!) reported by hg parents. This revision
  > >   > >   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
  > >   > > 
  > >   > > . is not usable in all cases.   For the example above:
  > >   > > 
  > >   > > hg log -r . foo.txt 
  > >   > > 
  > >   > > does not work, it does not show anything.
  > >   > 
  > >   > I just tested it with the above commands and it works at least as far
  > >   > back as 1.0.
  > > 
  > >  cat foo.txt
  > > foo
  > > $ hg parents foo.txt 
  > > changeset:   0:1ac3a9e3757e
  > > user:        blah@blah.com
  > > date:        Thu Dec 17 08:06:39 2009 -0800
  > > summary:     Added foo.txt
  > > 
  > > $ hg log foo.txt 
  > > changeset:   1:6d88f588d323
  > > branch:      bar
  > > user:        blah@blah.com
  > > date:        Thu Dec 17 08:06:39 2009 -0800
  > > summary:     Changed foo to bar
  > > 
  > > changeset:   0:1ac3a9e3757e
  > > user:        blah@blah.com
  > > date:        Thu Dec 17 08:06:39 2009 -0800
  > > summary:     Added foo.txt
  > > 
  > > $ hg log -r . foo.txt 
  > > $ env HGRC= hg log -r . foo.txt
  > 
  > There's no such environment variable. Perhaps you want HGRCPATH.
  > 
  > > $ hg --version
  > > Mercurial Distributed SCM (version 1.4)
  > > 
  > > Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others
  > > This is free software; see the source for copying conditions. There is NO
  > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  > > 
  > > This is on an up to date Fedora 12 machine.
  > > 
  > > Is your output different.
  > 
  > Yes. The following script:
  > 
  > #!/bin/sh
  > 
  > rm -rf a
  > hg init a
  > cd a
  > 
  > echo foo > foo.txt
  > hg add foo.txt
  > hg commit -qm "Added foo.txt"
  > hg branch -q bar
  > echo bar > foo.txt
  > hg commit -qm "Changed foo to bar"
  > hg update -qr default
  > echo frobozz > frobozz.txt
  > hg add frobozz.txt
  > hg commit -qm "Added frobozz.txt"
  > hg annotate -r . foo.txt
  > 
  > gives me:
  > 
  > 0: foo

I think we are miscommunicating.  I have stated already that "-r ."
works fine for "hg annotate".
Please re-read the output I gave above it is for "hg log", NOT "hg
annotate".
With your script "hg log -r . foo.txt" does not show anything.

The point here is that "-r ." CANNOT be used in all contexts to show
information about a file.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Re: C-x v i bug

[Matt Mackall]

On Fri, 2009-12-18 at 12:08 -0800, Dan Nicolaescu wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
>   > On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote:
>   > > Matt Mackall <mpm@selenic.com> writes:
>   > > 
>   > >   > On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
>   > >   > > Matt Mackall <mpm@selenic.com> writes:
>   > >   > > 
>   > >   > >   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
>   > >   > >   > > Martin Geisler <mg@lazybytes.net> writes:
>   > >   > >   > > 
>   > >   > >   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > >   > >   > >   > 
>   > >   > >   > >   > > Let's first talk about the original problem that started this
>   > >   > >   > >   > > discussion.
>   > >   > >   > >   > >
>   > >   > >   > >   > > When a file in a directory that is under mercurial control is opened
>   > >   > >   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
>   > >   > >   > >   > > registered or not, if it's modified, etc.
>   > >   > >   > >   > >
>   > >   > >   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
>   > >   > >   > >   > 
>   > >   > >   > >   > Right. Many people use the color extension to get better feedback from
>   > >   > >   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
>   > >   > >   > >   > disable itself. I'm just mentioning color to say that there are useful
>   > >   > >   > >   > extensions out there that modify even basic commands like 'hg status'.
>   > >   > >   > >   > 
>   > >   > >   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
>   > >   > >   > >   > > initializing plugins will just waste time.
>   > >   > >   > >   > > After that emacs will want to know the version number for the file, for that
>   > >   > >   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
>   > >   > >   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
>   > >   > >   > >   > 
>   > >   > >   > >   > Right, and it's even quite important that you disable localization (run
>   > >   > >   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
>   > >   > >   > >   > 
>   > >   > >   > >   >   % hg log -l1 README
>   > >   > >   > >   >   ændring:     9586:a41f2840f9c6
>   > >   > >   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
>   > >   > >   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
>   > >   > >   > >   >   uddrag:      README: revert accidental commit
>   > >   > >   > >   > 
>   > >   > >   > >   > The user could also very well have installed a different default style
>   > >   > >   > >   > by setting ui.style. On the command line it's done line this:
>   > >   > >   > > 
>   > >   > >   > > Thank you, this was very useful in taking care of some issues in emacs.
>   > >   > >   > > 
>   > >   > >   > >   >   % hg log -l1 README --style=compact
>   > >   > >   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
>   > >   > >   > >   >     README: revert accidental commit
>   > >   > >   > >   > 
>   > >   > >   > >   > > [too bad that the status and version number are not available from a
>   > >   > >   > >   > > single command...]
>   > >   > >   > >   > 
>   > >   > >   > >   > Well, you know, files don't really have a version number with modern
>   > >   > >   > >   > version control systems. The entire tree has a version number... You can
>   > >   > >   > >   > of course ask about when a file was last touched, but I think that
>   > >   > >   > >   > information is getting more and more irrelevant these days.
>   > >   > >   > > 
>   > >   > >   > > In emacs the generic Version Control layer needs a version number in some case.
>   > >   > >   > > Here's an example from a bug report:
>   > >   > >   > > 
>   > >   > >   > > cd  /tmp
>   > >   > >   > > mkdir hgtest2
>   > >   > >   > > cd hgtest2
>   > >   > >   > > hg init
>   > >   > >   > > echo foo > foo.txt
>   > >   > >   > > hg add foo.txt
>   > >   > >   > > hg commit -m "Added foo.txt"
>   > >   > >   > > hg branch bar
>   > >   > >   > > echo bar > foo.txt
>   > >   > >   > > hg commit -m "Changed foo to bar"
>   > >   > >   > > hg update -r default
>   > >   > >   > > echo frobozz > frobozz.txt
>   > >   > >   > > hg add frobozz.txt
>   > >   > >   > > hg commit -m "Added frobozz.txt"
>   > >   > >   > > 
>   > >   > >   > > 
>   > >   > >   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
>   > >   > >   > > annotated version, emacs does that by running
>   > >   > >   > > 
>   > >   > >   > > hg annotate -r REVISION foo.txt
>   > >   > >   > >
>   > >   > >   > > How can REVISION be obtained in this case?
>   > >   > >   > > It should be "0", but
>   > >   > >   > > hg log -l1 foo.txt
>   > >   > >   > > does not show that...
>   > >   > >   > 
>   > >   > >   > Version numbers are not per-file in Mercurial. The number you should use
>   > >   > >   > is the global number (or numbers!) reported by hg parents. This revision
>   > >   > >   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
>   > >   > > 
>   > >   > > . is not usable in all cases.   For the example above:
>   > >   > > 
>   > >   > > hg log -r . foo.txt 
>   > >   > > 
>   > >   > > does not work, it does not show anything.
>   > >   > 
>   > >   > I just tested it with the above commands and it works at least as far
>   > >   > back as 1.0.
>   > > 
>   > >  cat foo.txt
>   > > foo
>   > > $ hg parents foo.txt 
>   > > changeset:   0:1ac3a9e3757e
>   > > user:        blah@blah.com
>   > > date:        Thu Dec 17 08:06:39 2009 -0800
>   > > summary:     Added foo.txt
>   > > 
>   > > $ hg log foo.txt 
>   > > changeset:   1:6d88f588d323
>   > > branch:      bar
>   > > user:        blah@blah.com
>   > > date:        Thu Dec 17 08:06:39 2009 -0800
>   > > summary:     Changed foo to bar
>   > > 
>   > > changeset:   0:1ac3a9e3757e
>   > > user:        blah@blah.com
>   > > date:        Thu Dec 17 08:06:39 2009 -0800
>   > > summary:     Added foo.txt
>   > > 
>   > > $ hg log -r . foo.txt 
>   > > $ env HGRC= hg log -r . foo.txt
>   > 
>   > There's no such environment variable. Perhaps you want HGRCPATH.
>   > 
>   > > $ hg --version
>   > > Mercurial Distributed SCM (version 1.4)
>   > > 
>   > > Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others
>   > > This is free software; see the source for copying conditions. There is NO
>   > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>   > > 
>   > > This is on an up to date Fedora 12 machine.
>   > > 
>   > > Is your output different.
>   > 
>   > Yes. The following script:
>   > 
>   > #!/bin/sh
>   > 
>   > rm -rf a
>   > hg init a
>   > cd a
>   > 
>   > echo foo > foo.txt
>   > hg add foo.txt
>   > hg commit -qm "Added foo.txt"
>   > hg branch -q bar
>   > echo bar > foo.txt
>   > hg commit -qm "Changed foo to bar"
>   > hg update -qr default
>   > echo frobozz > frobozz.txt
>   > hg add frobozz.txt
>   > hg commit -qm "Added frobozz.txt"
>   > hg annotate -r . foo.txt
>   > 
>   > gives me:
>   > 
>   > 0: foo
> 
> I think we are miscommunicating.  I have stated already that "-r ."
> works fine for "hg annotate".
> Please re-read the output I gave above it is for "hg log", NOT "hg
> annotate".
> With your script "hg log -r . foo.txt" does not show anything.

I see.

> The point here is that "-r ." CANNOT be used in all contexts to show
> information about a file.

You might find 'hg log -fql1 <file>' helpful.

-- 
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel