[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1233 - Properties in the client unit tests

From: Matthew Hambley <matthew_at_aether.demon.co.uk>
Date: 2003-04-27 12:14:51 CEST

In message <85bryskefm.fsf@newton.ch.collab.net>
          kfogel@collab.net wrote:

> Matthew Hambley <matthew@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
Received on Sun Apr 27 12:16:11 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.