Re: Tests fail on Windows

On Sun, Jul 19, 2009 at 12:50 PM, Michael Haggerty<[email protected]> wrote:
> Probably the "correct" solution is for svntest not to parse the text
> output of "svn log" at all but rather to use "svn log --xml" and parse
> the XML output.  Presumably the Subversion project makes adequate
> guarantees as to the backwards-compatibility of the XML output.
> Probably this change should be implemented upstream.  But I haven't
> pursued this.  The main questions are:
>
> - Does the XML output contain all of the information needed by svntest?
>
> - Is the XML output consistent across SVN versions (at least with
> regards to the information needed by svntest)?
>
> - Is there some reason that the Subversion project doesn't want to use
> the XML output?
>
> If you would like to look into this, that would be great.

I sent a message to the dev mailing list for more information.


> Thanks, good catch.  It seems to me that it makes sense (on Windows) to
> make the code work for either '/' or '\' and also to ignore the case of
> the filenames.  So that is what I implemented (using os.path.normpath()
> and os.path.normcase()) in trunk r4821.  Please let me know whether this
> works for you.

Aha, I didn't know about those functions.  It works for me.


> I like the concept.  I was puzzled that you didn't include the
> passbypass, options_file, and symbol_hints_file options in the hash but
> rather kept them as parts of the filenames--doesn't this also make for
> long filenames?

It does but they weren't long enough to cause problems for me.  The
longest directory name was because of many items being passed in args,
many of which had special characters.  Each of those characters would
get escaped, making the length even longer.  The passbypass,
options_file and symbol_hints_file options were, by contrast, of
fairly small maximum length and had no special characters in need of
escaping.


> So I tried moving these options into the hash, too, but (as you
> undoubtedly noticed) the options-file-based test cases have to know the
> path to which the repository should be output, so it doesn't work.

I did notice the conflict with the options-file-based tests.  At first
I tried putting in the hash unconditionally, even if args was the
empty list.  Then the MD5 of the empty string (d41d8...) would end up
in the resulting directory name.  I thought about changing the names
in the options files but realized it was easier just to avoid the
issue by not including the hash in the case where args was empty.  I
didn't try putting the options_file into the hash as you have though.


> So as trunk r4825 I committed something similar to your code, except
> that it moves all of the parameters *except* --options into the hash.
> It seems to work; let me know if it is OK for you.

It works for me.


> By the way, if you submit more patches in the future, it would be
> helpful if you would submit a separate patch for each logically-separate
> change.

Will do.  Thanks for helping me with this.

-- 
James Abbatiello

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2372810

To unsubscribe from this discussion, e-mail: [[email protected]].