I've filed this as issue 612 in the Mercurial bug tracker.
Stephen Lau wrote:
> Stephen Lau wrote:
>> Richard Lowe wrote:
>>> Richard Lowe wrote:
>>>> Stephen Lau wrote:
>>>>> Richard Lowe wrote:
>>>>>> Can someone else build a pre-winchester onnv, then bringover the
>>>>>> Winchester putback and see if they see similar? This is with the
>>>>>> current SUNWmercurial Danek put up, not 0.9.3, or 0.9.4 (I'm
>>>>>> working on updating our stuff for 0.9.4, and getting 0.9.4
>>>>>> packaged for us, and into sfwnv (probably) now...).
>>>>>
>>>>> Ka-boom. I was able to reproduce part of this (list of files
>>>>> below). Though unlike Rich, I didn't have any changes to commit.
>>>>> Attempting a 'hg commit' just shows "(nothing changed)", and 'hg
>>>>> st' doesn't show any changes.
>>>>>
>>>>
>>>> Yeah, everyone can do that bit. Now, why do I see them in the
>>>> dirstate, and why can I commit that junk? 'hg st -mard' doesn't
>>>> show you !'d files from the source part?
>>>
>>> Ok, what state does it think files that were previously not
>>> controlled are in?
>>>
>>> hg st <one of the libsqlite objects>
>>> hg debugstate | grep '/libsqlite/'
>>>
>>> Do you see them in the dirstate in either case? I do, and a rebuild
>>> of libsqlite will show the make.state as modified (and it will commit
>>> it, if I commit...)
>>>
>>> -- Rich
>>
>> Yup, I was able to reproduce this fully now. Here's what I did:
>> hg clone -r 4519 ssh://anon at hg.opensolaris.org/hg/onnv/onnv-gate
>> ran a full build (probably unnecessary - it might be sufficient to
>> just build usr/src/cmd/svc/configd/sqlite).
>> hg pull -u -r 4520
>> bldenv -d developer.sh
>> cd usr/src/lib/libsqlite
>> dmake all
>> hg status -mard
>>
>> so hg status now shows:
>> [stevel at zday:libsqlite] 502$ hg st -mard
>> M usr/src/lib/libsqlite/.make.state
>>
>> So it thinks .make.state is tracked when it shouldn't be.
>>
>> This should probably be marked as a stopper - committing things which
>> shouldn't be under revision control is bad.
>>
>> cheers,
>> steve
>>
>
> Here's an even simpler test case to reproduce that doesn't involve
> onnv-gate (so should be easier for mpm to debug):
>
> $ hg init hg-parent
> $ cd hg-parent
> $ mkdir dir
> $ cd dir
> $ cat <<EOF >a.c
> > #include <stdio.h>
> > int main() {printf("hello world");}
> > EOF
> $ hg add a.c
> $ hg commit -m "Added a.c"
> $ cd ../..
> $ hg clone hg-parent hg-child
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ cd hg-child/dir
> $ cc a.c
> $ cd ../../hg-parent
> $ hg rename dir newdir
> copying dir/a.c to newdir/a.c
> removing dir/a.c
> $ hg commit -m "Renamed dir->newdir"
> $ cd ../hg-child
> $ hg pull -u
> pulling from /home/stevel/hg-parent
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files
> not in dirstate: dir/a.out!
> 2 files updated, 0 files merged, 1 files removed, 0 files unresolved
> $ cd newdir
> $ cc a.c
> $ hg st
> M newdir/a.out
>
>
> So it now thinks a.out is under SCM control when it shouldn't be.
>
> cheers,
> steve
--
stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
