hg id behavior bug?

[Peter Arrenbrecht]

On Wed, Jan 21, 2009 at 1:57 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2009-01-20 at 16:10 -0800, Tracy Reed wrote:
>> I am writing a Makefile and I want to include the version of the
>> current build into a sort of version.txt automatically. The output of
>> "hg id" seems perfect for this. I also like the fact that it appends a
>> + to the version number for uncommitted changes. This way I can
>> disallow any version containing a + from being used in production.
>>
>> I also have a couple of other repositories that get checked out next
>> to this one which get pulled in to build the final product. So I want
>> to include their versions as well. So in my Makefile I do "hg id" for
>> my current repo and then I do "hg id ../other-project" to get the
>> version from over there.
>>
>> But I notice that "hg id" does not include the + for uncommitted
>> changes or the tag when you provide it a path to check in. Is this a
>> bug or is there a particular reason for doing this?
>>
>> Example:
>>
>> ~/ew/ew-dev $ hg id .
>> 9b1b54763c86
>> ~/ew/ew-dev $ hg id
>> 9b1b54763c86+ tip
>
> The behavior with a path supplied is quite different:
>
> "With a path, do a lookup in another repository."
>
> hg id <repo> looks up the 'tip' revision of the specified repository.
> The repository is presumed to be remote, and as such, it doesn't look at
> the working directory AT ALL, so it doesn't even look at what version is
> checked out, nevermind if there are any changes.

Tracy, you might want to be using

$ hg -R /the/other/repo id

-parren