[BUG] t9101 (master) busted on Leopard

[BUG] t9101 (master) busted on Leopard

[Wincent Colaiuta]

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.

This is the specific test that's failing:

* FAIL 25: test propget
git-svn propget svn:ignore . | cmp - prop.expect &&
cd deeply &&
git-svn propget svn:ignore . | cmp - ../prop.expect &&
git-svn propget svn:entry:committed-rev nested/directory/.keep 	  |  
cmp - ../prop2.expect &&
git-svn propget svn:ignore .. | cmp - ../prop.expect &&
git-svn propget svn:ignore nested/ | cmp - ../prop.expect &&
git-svn propget svn:ignore ./nested | cmp - ../prop.expect &&
git-svn propget svn:ignore .././deeply/nested | cmp - ../prop.expect

The problem is that the for line:

git-svn propget svn:entry:committed-rev nested/directory/.keep

The test expects the "8", but it actually yields "7".

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.

Cheers,
Wincent

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

[Brian Gernhardt]

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?

~~ Brian

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

[Wincent Colaiuta]

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.

Cheers,
Wincent

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

[Benoit Sigoure]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

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).

Thanks.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Wincent Colaiuta]

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

> 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).

Yes, have just sent you the output of "--verbose" and also running the  
script using "sh -x" (off list).

Cheers,
Wincent

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

[Wincent Colaiuta]

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

> 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

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

[Björn Steinbrink]

On 2007.11.16 12:00:02 +0100, Wincent Colaiuta wrote:
> El 15/11/2007, a las 22:13, Benoit Sigoure escribió:
>> 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

It _is_ a no-op. At least here. Because I got an auto-props setting in
my ~/.subversion/config to automatically add Id for *.c files. So that
property was already there before we explicitly ask for it and the
propset turns into a no-op. If I remove that line from the subversion
configuration, the test succeeds. Same for you I guess.

That said, I had a quick glance over the subversion CLI help, but it
didn't tell me how to ignore/override ~/.subversion/config. Anyone less
clueless than me around, having a smart idea how to work around that
"bug"?

Björn

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

[Wincent Colaiuta]

El 16/11/2007, a las 13:48, Björn Steinbrink escribió:
> On 2007.11.16 12:00:02 +0100, Wincent Colaiuta wrote:
>> 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
>
> It _is_ a no-op. At least here. Because I got an auto-props setting in
> my ~/.subversion/config to automatically add Id for *.c files. So that
> property was already there before we explicitly ask for it and the
> propset turns into a no-op. If I remove that line from the subversion
> configuration, the test succeeds. Same for you I guess.
>
> That said, I had a quick glance over the subversion CLI help, but it
> didn't tell me how to ignore/override ~/.subversion/config. Anyone  
> less
> clueless than me around, having a smart idea how to work around that
> "bug"?

Ah, excellent catch, Björn. That's it. The --no-auto-props switch will  
fix this then; will post a patch to the list in a few minutes.

Cheers,
Wincent

[PATCH] Fix t9101 test failure caused by Subversion "auto-props"

[Wincent Colaiuta]

If a user has an "auto-prop" in his/her ~/.subversion/config file for
automatically setting the svn:keyword Id property on all ".c" files
(a reasonably common configuration in the Subversion world) then one
of the "svn propset" operations in the very first test would become a
no-op, which in turn would make the next commit a no-op.

This then caused the 25th test ('test propget') to fail because it
expects a certain number of commits to have taken place but the actual
number of commits was off by one.

Björn Steinbrink identified the "auto-prop" feature as the cause
of the failure. This patch avoids it by passing the "--no-auto-prop"
flag to "svn import" when setting up the test repository, thus ensuring
that the "svn propset" operation is no longer a no-op, regardless of the
users' settings in their config.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
  t/t9101-git-svn-props.sh |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 3c83127..d7a7047 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -48,7 +48,7 @@ EOF
         printf "\r\n" > empty_crlf
         a_empty_crlf=`git-hash-object -w empty_crlf`

-       svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
+       svn import --no-auto-props -m 'import for git-svn' .  
"$svnrepo" >/dev/null
  cd ..

  rm -rf import
-- 
1.5.3.5

Re: [PATCH] Fix t9101 test failure caused by Subversion "auto-props"

[Benoit Sigoure]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Nov 16, 2007, at 2:25 PM, Wincent Colaiuta wrote:

> If a user has an "auto-prop" in his/her ~/.subversion/config file for
> automatically setting the svn:keyword Id property on all ".c" files
> (a reasonably common configuration in the Subversion world) then one
> of the "svn propset" operations in the very first test would become a
> no-op, which in turn would make the next commit a no-op.
>
> This then caused the 25th test ('test propget') to fail because it
> expects a certain number of commits to have taken place but the actual
> number of commits was off by one.
>
> Björn Steinbrink identified the "auto-prop" feature as the cause
> of the failure. This patch avoids it by passing the "--no-auto-prop"
> flag to "svn import" when setting up the test repository, thus  
> ensuring
> that the "svn propset" operation is no longer a no-op, regardless  
> of the
> users' settings in their config.
>
> Signed-off-by: Wincent Colaiuta <win@wincent.com>
> ---
>  t/t9101-git-svn-props.sh |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
> index 3c83127..d7a7047 100755
> --- a/t/t9101-git-svn-props.sh
> +++ b/t/t9101-git-svn-props.sh
> @@ -48,7 +48,7 @@ EOF
>         printf "\r\n" > empty_crlf
>         a_empty_crlf=`git-hash-object -w empty_crlf`
>
> -       svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
> +       svn import --no-auto-props -m 'import for git-svn' .  
> "$svnrepo" >/dev/null
>  cd ..
>
>  rm -rf import

Great, thank you for tackling this issue.  It wasn't easy to find.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] Fix t9101 test failure caused by Subversion "auto-props"

[Junio C Hamano]

Wincent Colaiuta <win@wincent.com> writes:

> If a user has an "auto-prop" in his/her ~/.subversion/config file for
> automatically setting the svn:keyword Id property on all ".c" files
> (a reasonably common configuration in the Subversion world) then one
> of the "svn propset" operations in the very first test would become a
> no-op, which in turn would make the next commit a no-op.

Thanks for diagnosing and fixing.

I presume this fix also applies to both 'maint' and 'master',
right?

Re: [PATCH] Fix t9101 test failure caused by Subversion "auto-props"

[Wincent Colaiuta]

El 17/11/2007, a las 1:19, Junio C Hamano escribió:

> Wincent Colaiuta <win@wincent.com> writes:
>
>> If a user has an "auto-prop" in his/her ~/.subversion/config file for
>> automatically setting the svn:keyword Id property on all ".c" files
>> (a reasonably common configuration in the Subversion world) then one
>> of the "svn propset" operations in the very first test would become a
>> no-op, which in turn would make the next commit a no-op.
>
> Thanks for diagnosing and fixing.
>
> I presume this fix also applies to both 'maint' and 'master',
> right?

I prepared it against master, but I believe it will apply cleanly to  
maint, where it's also needed.

Cheers,
Wincent

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

[Väinö Järvelä]

On Nov 15, 2007, at 18:11, 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.

I cannot reproduce this on Leopard (not yet updated to 10.5.1). I  
tested this with self-compiled GIT from commit id ca2b71c

svn version is the same as yours, I do use Fink, and I have used Fink  
to install Perl SVN bindings.

--
Väinö

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

[Wincent Colaiuta]

El 16/11/2007, a las 5:25, Väinö Järvelä escribió:

> On Nov 15, 2007, at 18:11, Wincent Colaiuta wrote:
>
>> 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.
>
> I cannot reproduce this on Leopard (not yet updated to 10.5.1). I  
> tested this with self-compiled GIT from commit id ca2b71c
>
> svn version is the same as yours, I do use Fink, and I have used  
> Fink to install Perl SVN bindings.

Strange. I've looked in the environment and there is nothing  
suspicious; in fact, running the tests with a totally clean  
environment (env -i ./t9101-git-svn-props.sh) produces exactly the  
same result.

This was with commit 039bc64e (HEAD of master yesterday). I just  
tested the commit you mention (HEAD of next) and get the same failure;  
this is the procedure I'm using to test:

git fetch
git checkout -b next_test origin/next
git describe # (v1.5.3.5-1780-gca2b71c)
git clean
make clean && make
cd t
env -i ./t9101-git-svn-props.sh

So really, not sure what could be causing this.

Cheers,
Wincent

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

[Väinö Järvelä]

On Nov 16, 2007, at 10:37, Wincent Colaiuta wrote:

> El 16/11/2007, a las 5:25, Väinö Järvelä escribió:
>
>> On Nov 15, 2007, at 18:11, Wincent Colaiuta wrote:
>>
>>> 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.
>>
>> I cannot reproduce this on Leopard (not yet updated to 10.5.1). I  
>> tested this with self-compiled GIT from commit id ca2b71c
>>
>> svn version is the same as yours, I do use Fink, and I have used  
>> Fink to install Perl SVN bindings.
>
> Strange. I've looked in the environment and there is nothing  
> suspicious; in fact, running the tests with a totally clean  
> environment (env -i ./t9101-git-svn-props.sh) produces exactly the  
> same result.
>
> This was with commit 039bc64e (HEAD of master yesterday). I just  
> tested the commit you mention (HEAD of next) and get the same  
> failure; this is the procedure I'm using to test:
>
> git fetch
> git checkout -b next_test origin/next
> git describe # (v1.5.3.5-1780-gca2b71c)
> git clean
> make clean && make
> cd t
> env -i ./t9101-git-svn-props.sh
>
> So really, not sure what could be causing this.

Did you forget to install the newly compiled version? Or does the test  
system use git from the source tree?

--
Väinö

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

[Wincent Colaiuta]

El 16/11/2007, a las 9:59, Väinö Järvelä escribió:

> On Nov 16, 2007, at 10:37, Wincent Colaiuta wrote:
>
>> Strange. I've looked in the environment and there is nothing  
>> suspicious; in fact, running the tests with a totally clean  
>> environment (env -i ./t9101-git-svn-props.sh) produces exactly the  
>> same result.
>>
>> This was with commit 039bc64e (HEAD of master yesterday). I just  
>> tested the commit you mention (HEAD of next) and get the same  
>> failure; this is the procedure I'm using to test:
>>
>> git fetch
>> git checkout -b next_test origin/next
>> git describe # (v1.5.3.5-1780-gca2b71c)
>> git clean
>> make clean && make
>> cd t
>> env -i ./t9101-git-svn-props.sh
>>
>> So really, not sure what could be causing this.
>
> Did you forget to install the newly compiled version? Or does the  
> test system use git from the source tree?

I didn't install the newly compiled version because, as far as know,  
the test system uses the built copy in the source tree (I can't  
actually recall *any* Makefile-based open source projects that didn't  
work like that).

$ git --version
git version 1.5.3.5
$ /usr/local/bin/git --version
git version 1.5.3.5
$ ./git --version # (from inside the source tree)
git version 1.5.3.5.1780.gca2b
$ env -i git --version
env: git: No such file or directory

So the test run above *must* be using the just-built copy in the  
source tree otherwise *none* of the tests would pass.

Cheers,
Wincent