A bit embarrassing when you send your first patch to a dev-list, to
notice a few seconds later that you took the wrong file.
Attached patch should be correct.
Sorry.
Lieven.
On Wed, 2005-08-03 at 22:33 +0200, Lieven Govaerts wrote:
> Hi,
>
> I encountered a situation this morning ( which I first mailed to the
> users-list ) in which the xml generated by svn log --xml, and more
> specific svn_client_log2, is invalid.
>
> Consequences are:
> 1. Validation of xml with the current DTD files fails.
> 2. JavaHL bindings will crash the Java VM when parsing the xml!
>
> The situation is very specific, but easily reproduced with apache &
> subversion.
>
> I have a public repository at http://www.mobsol.be/svn/public, which is
> world readable. In that repository I have a branch branches/1.0, which
> is private, and can only be read with correct credentials.
>
> My svnaccess.conf:
> ...
> [public:/]
> * = r
> @publicdev = rw
>
> [public:/branches/1.0]
> *=
> @publicdev = rw
> ...
>
> My apache is configured to first try anonymous access to the repository
> for read-only actions:
> ( extract of httpd subversion.conf )
> ...
> <Limit GET PROPFIND OPTIONS REPORT>
> Satisfy any
> </Limit>
> ...
> Require valid-user
>
> This works without problem in most situations.
>
> But, when I request the log of this repository ( feel free to try ), I
> get:
>
> # svn log http://www.mobsol.be/svn/public
> ...
> ------------------------------------------------------------------------
> r14 | (no author) | (no date) | 1 line
>
> ------------------------------------------------------------------------
> r13 | (no author) | (no date) | 1 line
> ...
>
> Since the target of svn log is in the public zone, no credentials are
> asked. Later, revision 13 & 14 alter files in the branches/1.0 folder,
> which is private. Since no credentials were asked at first, svn log
> cannot read these specific revisions.
>
> This seems a bit tricky, but is understandable and probably correct
> behaviour.
>
> The two consequenses:
> 1. When asking for XML output, this results in logentries with undefined
> author&date tags:
> ...
> <logentry
> revision="14">
> <msg></msg>
> </logentry>
> <logentry
> revision="13">
> <msg></msg>
> </logentry>
> ...
> This is not allowed according to log.dtd, so I guess this is a problem.
>
> I have no real suggestion how this should be solved since I don't know
> how handling this situation is specified.
>
> 2. I made a Java application using the javahl bindings, doing the same
> log request. Both on Windows as Linux this application will crash the
> Java VM.
> LogMessage[] lms = cl.logMessages("http://www.mobsol.be/svn/public",\
> null, null);
> System.out.println(lms.toString());
> This happens in the MessageReceiver callback function in SVNClient.cpp.
>
> Attached to this mail is a patch for SVNClient.cpp. The patch makes sure
> that the date object returned to the Java client is 'null' in this
> situation, by testing specifically for that situation. Other solution
> might be to fix function svn_time_from_cstring to return NULL when date
> is NULL.
>
> [[[
>
> * subversion/bindings/java/javahl/native/SVNClient.cpp
> SVNClient::messageReceiver: Check if date of the revision is not NULL,
> before trying to convert to the apr_time_t format.
>
> ]]]
>
> Hope this makes sense.
>
> Lieven.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 3 22:49:29 2005