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
