You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Matthew Hambley <ma...@aether.demon.co.uk> on 2003/04/26 09:32:13 UTC
Properties in the client unit tests
Right, this is driving me spare!
Due to the thundering silence which met my request for help with my patch
I've been blundering around in the build process trying to figure it out
for myself. I've solved the problem of my unit tests not being run by
'make check'. (although I'm not entirely sure how) Unfortunately this has
thrown up a new problem. My patch doesn't break subversion (as far as I
know) but it does break the tests. Now that every file is given a MIME
type property tests which do not expect it to have one are failing.
So now I can't work out how to modify the tests to deal with this. I've
tried every permutation I can think of but always with the same result.
Something somewhere complains that either it was expecting the property but
didn't find it or that it found the property but wasn't expecting it.
Where should I put this information so that those stages which don't find
it don't expect it and those which do, do?
--
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk \ doing badly until you can learn to
Public key : C991137B \ do it well.
Web : http://www.aether.demon.co.uk/ \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by Matthew Hambley <ma...@aether.demon.co.uk>.
In message <m3...@localhost.localdomain>
cmpilato@collab.net wrote:
> Matthew Hambley <ma...@aether.demon.co.uk> writes:
>
> > > Right. Because in that test, we actually want to verify properties.
> > > In order for this test to pass for you, you'll need to tell the test
> > > suite what mime-type properties to expect for every file in the
> > > working copy. See other tests which deal with props for examples.
> >
> > And as explained in my original posting if I update main.greek_state to
> > hold the new properties the tests pass only to fail later on complaining
> > that they are expecting the property but it isn't there.
>
> Yeah, I missed that in your original posting. Sussman set me
> straight, though. Sorry 'bout that.
No problem.
--
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk \ doing badly until you can learn to
Public key : C991137B \ do it well.
Web : http://www.aether.demon.co.uk/ \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by cm...@collab.net.
Matthew Hambley <ma...@aether.demon.co.uk> writes:
> > Right. Because in that test, we actually want to verify properties.
> > In order for this test to pass for you, you'll need to tell the test
> > suite what mime-type properties to expect for every file in the
> > working copy. See other tests which deal with props for examples.
>
> And as explained in my original posting if I update main.greek_state to
> hold the new properties the tests pass only to fail later on complaining
> that they are expecting the property but it isn't there.
Yeah, I missed that in your original posting. Sussman set me
straight, though. Sorry 'bout that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by Matthew Hambley <ma...@aether.demon.co.uk>.
In message <m3...@localhost.localdomain>
cmpilato@collab.net wrote:
> Matthew Hambley <ma...@aether.demon.co.uk> writes:
>
> > In message <86...@kepler.ch.collab.net>
> > Ben Collins-Sussman <su...@collab.net> wrote:
> >
> > > Matthew Hambley <ma...@aether.demon.co.uk> writes:
> > >
> > > > So where have the properties gone? Well the walk-back at the end
> > > > suggests that it's a problem in the repository. (Ignoring for the
> > > > moment that the property was there previously) So I cd into
> > > > working_copies/basic_tests-14 and do a 'svn propget svn:mime-type
> > > > new_file' which returns 'text/plain' as expected.
> > >
> > > Let me give you a clue: look at the last argument to
> > > svntest.actions.run_and_verify_update(). It's a boolean that
> > > indicates whether props should be scanned from the working copy.
> > > It's off by default, because most of the time we don't care about
> > > them, and having it turned on drastically slows down our tests.
> >
> > Thanks for the suggestion but if you check basic_test.py,
> > basic_import(..) you will see that that parameter is already set to
> > '1'.
>
> Right. Because in that test, we actually want to verify properties.
> In order for this test to pass for you, you'll need to tell the test
> suite what mime-type properties to expect for every file in the
> working copy. See other tests which deal with props for examples.
And as explained in my original posting if I update main.greek_state to
hold the new properties the tests pass only to fail later on complaining
that they are expecting the property but it isn't there.
--
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk \ doing badly until you can learn to
Public key : C991137B \ do it well.
Web : http://www.aether.demon.co.uk/ \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by cm...@collab.net.
Matthew Hambley <ma...@aether.demon.co.uk> writes:
> In message <86...@kepler.ch.collab.net>
> Ben Collins-Sussman <su...@collab.net> wrote:
>
> > Matthew Hambley <ma...@aether.demon.co.uk> writes:
> >
> > > So where have the properties gone? Well the walk-back at the end
> > > suggests that it's a problem in the repository. (Ignoring for the
> > > moment that the property was there previously) So I cd into
> > > working_copies/basic_tests-14 and do a 'svn propget svn:mime-type
> > > new_file' which returns 'text/plain' as expected.
> >
> > Let me give you a clue: look at the last argument to
> > svntest.actions.run_and_verify_update(). It's a boolean that indicates
> > whether props should be scanned from the working copy. It's off by
> > default, because most of the time we don't care about them, and having it
> > turned on drastically slows down our tests.
>
> Thanks for the suggestion but if you check basic_test.py, basic_import(..)
> you will see that that parameter is already set to '1'.
Right. Because in that test, we actually want to verify properties.
In order for this test to pass for you, you'll need to tell the test
suite what mime-type properties to expect for every file in the
working copy. See other tests which deal with props for examples.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by Matthew Hambley <ma...@aether.demon.co.uk>.
In message <86...@kepler.ch.collab.net>
Ben Collins-Sussman <su...@collab.net> wrote:
> Matthew Hambley <ma...@aether.demon.co.uk> writes:
>
> > So where have the properties gone? Well the walk-back at the end
> > suggests that it's a problem in the repository. (Ignoring for the
> > moment that the property was there previously) So I cd into
> > working_copies/basic_tests-14 and do a 'svn propget svn:mime-type
> > new_file' which returns 'text/plain' as expected.
>
> Let me give you a clue: look at the last argument to
> svntest.actions.run_and_verify_update(). It's a boolean that indicates
> whether props should be scanned from the working copy. It's off by
> default, because most of the time we don't care about them, and having it
> turned on drastically slows down our tests.
Thanks for the suggestion but if you check basic_test.py, basic_import(..)
you will see that that parameter is already set to '1'.
--
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk \ doing badly until you can learn to
Public key : C991137B \ do it well.
Web : http://www.aether.demon.co.uk/ \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by Ben Collins-Sussman <su...@collab.net>.
Matthew Hambley <ma...@aether.demon.co.uk> writes:
> So where have the properties gone? Well the walk-back at the end suggests
> that it's a problem in the repository. (Ignoring for the moment that the
> property was there previously) So I cd into working_copies/basic_tests-14
> and do a 'svn propget svn:mime-type new_file' which returns 'text/plain' as
> expected.
Let me give you a clue: look at the last argument to
svntest.actions.run_and_verify_update(). It's a boolean that
indicates whether props should be scanned from the working copy. It's
off by default, because most of the time we don't care about them, and
having it turned on drastically slows down our tests.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1233 - Properties in the client unit tests
Posted by Matthew Hambley <ma...@aether.demon.co.uk>.
In message <85...@newton.ch.collab.net>
kfogel@collab.net wrote:
> Matthew Hambley <ma...@aether.demon.co.uk> writes:
> > Right, this is driving me spare!
> >
> > Due to the thundering silence which met my request for help with my
> > patch I've been blundering around in the build process trying to figure
> > it out for myself. I've solved the problem of my unit tests not being
> > run by
[snip]
> Your patch itself was not greeted with thundering silence, though.
True, perhapse my phraseology was a little overwrought. I was aware of the
issue filing.
> It was filed as issue #1233, and I added some commentary there which
> might explain the lack of help in fixing the tests, basically saying that
> the extra complexity wasn't worth the added functionality for pre-1.0.
> I'm not claiming that everyone agrees with that assessment -- merely that
> no one appears to disagree strongly enough to volunteer their time.
I was surprised by that comment. What with version numbers currently being
around 0.21 I assumed there was quite some way to go before v1. Is there
a "road map" anyware which I can look at?
> By the way, your mail above references neither the issue number, nor
> the mailing list archive URL for the mail in which you requested help,
> and describes the patch in question only by implication. This doesn't
> make it easy for people to help, even those who want to.
Fair comment.
> I don't know what to say about the property tests. It might be better
> if you post describing how one (small) test fails, and how you tried
> to make it pass, and what resulted. Generic descriptions like the
> above don't really help anyone help you, it just informs them that
> your having a problem.
OK. So, for example 'basic_test.py 14' (basic import of single new file)
in a virgin test environment outputs:
=============================================================
Expected new_file and actual new_file are different!
=============================================================
EXPECTED NODE TO BE:
=============================================================
* Node name: new_file
Path: __SVN_ROOT_NODE/new_file
Contents: some text
Properties: {}
Attributes: {}
Children: is a file.
=============================================================
ACTUAL NODE FOUND:
=============================================================
* Node name: new_file
Path: __SVN_ROOT_NODE/new_file
Contents: some text
Properties: {'svn:mime-type': 'text/plain'}
Attributes: {}
Children: is a file.
Unequal at node new_file
EXCEPTION: SVNTreeUnequal
Which is not surprising since import now MIME types all files as they come
in. So in 'basic_test.py' I see there is a comment telling me that the
expected_disk structure is 'disregarding props' so clearly I don't put
anything in there. The same is true of the expected_status structure.
Which leaves expected_output. Therefore I change the line
'new_file' : Item(status='A ')
to read
'new_file' : Item(props={'svn:mime-type' : 'text/plain'}, status='A ')
which gives the following result:
=============================================================
Expected new_file and actual new_file are different!
=============================================================
EXPECTED NODE TO BE:
=============================================================
* Node name: new_file
Path: working_copies/basic_tests-14/new_file
Contents: None
Properties: {'svn:mime-type': 'text/plain'}
Attributes: {'status': 'A '}
Children: is a file.
=============================================================
ACTUAL NODE FOUND:
=============================================================
* Node name: new_file
Path: working_copies/basic_tests-14/new_file
Contents: None
Properties: {}
Attributes: {'status': 'A '}
Children: is a file.
Unequal at node new_file
Unequal at node basic_tests-14
Unequal at node working_copies
EXCEPTION: SVNTreeUnequal
So where have the properties gone? Well the walk-back at the end suggests
that it's a problem in the repository. (Ignoring for the moment that the
property was there previously) So I cd into working_copies/basic_tests-14
and do a 'svn propget svn:mime-type new_file' which returns 'text/plain' as
expected.
So something is going wrong in the test harnes perhapse. I see in
actions.py (run_and_verify_update) that tree.build_tree_from_checkout is
called to get the result tree. Clearly the output of the checkout command
does not include property information. Is this the source of the problem?
If so why was property information being found previously?
The function verify_update, called by run_and_verify_update, calls
tree.build_tree_from_wc. This *does* harvest property information and if I
move the property definition to the expected_disk structure in
basic_import() then that error goes away. But 1) the comments state
"disregarding props" and 2) A new error turns up:
=============================================================
Expected iota and actual iota are different!
=============================================================
EXPECTED NODE TO BE:
=============================================================
* Node name: iota
Path: __SVN_ROOT_NODE/iota
Contents: This is the file 'iota'.
Properties: {}
Attributes: {}
Children: is a file.
=============================================================
ACTUAL NODE FOUND:
=============================================================
* Node name: iota
Path: __SVN_ROOT_NODE/iota
Contents: This is the file 'iota'.
Properties: {'svn:mime-type': 'text/plain'}
Attributes: {}
Children: is a file.
Unequal at node iota
EXCEPTION: SVNTreeUnequal
This relates to the so-called "greek tree" used for testing purposes.
Again the new import function has correctly identified the files and type
stamped them. The test is not expecting this so fails. A first stab at
solving this problem might be to edit main.greek_state to add the
properties.
This provides a repeat of the previous adventure. The error concerning
unexpected presence of properties is replaced by an error concerning
unexpected *absence* of properties. So where does this come from? Maybe
from get_virginal_state but that takes a copy of greek_state which I just
modified. At this point it should be pointed out that I have never used
Python before so I'm working in the dark a bit here. What does that
"tweak" method do? Is it stripping the properties off?
This is where the trail goes cold and I'm left wondering what to do?
--
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk \ doing badly until you can learn to
Public key : C991137B \ do it well.
Web : http://www.aether.demon.co.uk/ \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Properties in the client unit tests
Posted by kf...@collab.net.
Matthew Hambley <ma...@aether.demon.co.uk> writes:
> Right, this is driving me spare!
>
> Due to the thundering silence which met my request for help with my patch
> I've been blundering around in the build process trying to figure it out
> for myself. I've solved the problem of my unit tests not being run by
> 'make check'. (although I'm not entirely sure how) Unfortunately this has
> thrown up a new problem. My patch doesn't break subversion (as far as I
> know) but it does break the tests. Now that every file is given a MIME
> type property tests which do not expect it to have one are failing.
>
> So now I can't work out how to modify the tests to deal with this. I've
> tried every permutation I can think of but always with the same result.
> Something somewhere complains that either it was expecting the property but
> didn't find it or that it found the property but wasn't expecting it.
>
> Where should I put this information so that those stages which don't find
> it don't expect it and those which do, do?
Your patch itself was not greeted with thundering silence, though. It
was filed as issue #1233, and I added some commentary there which
might explain the lack of help in fixing the tests, basically saying
that the extra complexity wasn't worth the added functionality for
pre-1.0. I'm not claiming that everyone agrees with that assessment
-- merely that no one appears to disagree strongly enough to volunteer
their time.
By the way, your mail above references neither the issue number, nor
the mailing list archive URL for the mail in which you requested help,
and describes the patch in question only by implication. This doesn't
make it easy for people to help, even those who want to.
I don't know what to say about the property tests. It might be better
if you post describing how one (small) test fails, and how you tried
to make it pass, and what resulted. Generic descriptions like the
above don't really help anyone help you, it just informs them that
your having a problem.
Good luck,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org