Re: [BUG] t9101 (master) busted on Leopard

From: Wincent Colaiuta <win@wincent.com>
Date: Nov 16, 2007, 11:00 UTC
Message-ID: <73246E38-9C22-4279-A53E-678434238E5C@wincent.com>
In-Reply-To: <1D7CC3C0-46C1-40D9-AAD5-B9ADFF99B58A@lrde.epita.fr>

El 15/11/2007, a las 22:13, Benoit Sigoure escribió:

Show 40 quoted lines

> On Nov 15, 2007, at 5:11 PM, Wincent Colaiuta wrote:
>
>> El 15/11/2007, a las 17:04, Brian Gernhardt escribió:
>>
>>> On Nov 15, 2007, at 8:46 AM, Wincent Colaiuta wrote:
>>>
>>>> Was just running the test suite against the master branch and saw  
>>>> that t9101 is currently failing on Leopard, and a review with git- 
>>>> bisect indicates that it has been ever since it was first  
>>>> introduced (in commit 15153451). Not sure if this problem is  
>>>> Leopard-specific or not as I only have one machine.
>>>
>>> It is not a Leopard specific problem, as far as I can tell.  I  
>>> just ran the test and had no errors on my Leopard machine.  So  
>>> perhaps it's some other detail of your setup?
>>>
>>>> I'm not a git-svn user myself, but if there's anything I can do  
>>>> to help diagnose this problem further on Leopard please let me  
>>>> know.
>>>
>>> I just tested it using svn from fink and (after discovering it  
>>> exists) from Leopard.  No problems.  Do you have an old svn  
>>> package (client, admin, or perl binding) installed from Darwin  
>>> Ports or Fink perhaps?
>>
>> I don't use Darwin Ports or Fink, and this is a clean Leopard  
>> install (ie. nothing installed in /usr/local apart from git and a  
>> very small number of other tools that aren't related to Subversion).
>>
>> This is the output of "/usr/bin/svn --version":
>>
>> svn, version 1.4.4 (r25188)
>>   compiled Sep 23 2007, 22:32:34
>>
>> Perhaps then it is something in the environment.
>
> Hi Wincent,
> Can you reproduce this deterministically?  If yes, can you re-run  
> the test with the --verbose flag and post the gzipped output (or  
> send it to me if the list doesn't like this sort of attachment).

Inspecting the output of --verbose has allowed me to the point where things are failing; look at the very first test in t9101-git-svn- props.sh and witness the following:

- before the test we are at revision 1
- there are 3 "svn commits" in the test
- but it looks like only 2 of the commits proceed
- so the revision number goes up to 2 then 3, when it should be 4
- as a result, in one of the later tests we fail because the test  
expects revision 8 but we only have revision 7

Checked out revision 1.
*   ok 1: checkout working copy from svn

* expecting success: cd test_wc &&
		echo Greetings >> kw.c &&
		poke kw.c &&
		svn commit -m "Not yet an Id" &&
		echo Hello world >> kw.c &&
		poke kw.c &&
		svn commit -m "Modified file, but still not yet an Id" &&
		svn propset svn:keywords Id kw.c &&
		poke kw.c &&
		svn commit -m "Propset Id" &&
	cd ..
Sending        kw.c
Transmitting file data .
Committed revision 2.
Sending        kw.c
Transmitting file data .
Committed revision 3.
property 'svn:keywords' set on 'kw.c'
*   ok 2: setup some commits to svn

That last commit is a no-op because, for some reason, the svn propset before it is also a no-op:

svn propset svn:keywords Id kw.c

In other words, it echos "property 'svn:keyword' set on 'kw.c'" but if I insert an "svn status" as the next command then I get no output at all. If I run the exact same commands manually from the terminal then they work (ie. it is not a no-op and "svn status" shows that the file is modified).

Actually, it's not really a no-op, because if I insert an "svn proplist -v kw.c" I get:

Properties on 'kw.c':
   svn:keywords : Id

So the property is being set, it's just that "svn commit" and "svn status" don't recognize the file as being modified. The "poke" in the test has no effect (file still shows up as unmodified) and only modifying the actual content (ie. appending to it by inserting another "echo" statement) is enough to make that commit actually happen.

So now we know a bit more about *what* is happening, but I still don't know *why*. I'd start to suspect some kind of weird filesystem issue if it weren't for the fact that these same commands work when executed by hand outside of the test script.

Cheers, Wincent