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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
