[JIRA] Created: (CC-1025) SVN:parsePropgetReader doesn't properly parse externals

SVN:parsePropgetReader doesn't properly parse externals
-------------------------------------------------------

                 Key: CC-1025
                 URL: http://jira.public.thoughtworks.org/browse/CC-1025
             Project: CruiseControl
          Issue Type: Bug
          Components: Core Application
    Affects Versions: 2.8.4
            Reporter: Sjon Hortensius


There seems to be a bug in parsePropgetReader, which causes it to incorrectly process externals.

I have an app where /source/ contains two directories /applications/ and /modules/. Both of these have externals, so the svn propget command outputs:

> [unittest@unittest source]$ svn propget svn:externals -R
> applications - ^/react_v2/applications/React_ModelBuilder/branches/1.3	React_ModelBuilder-1.3
> ^/react_v2/applications/React_OAuthServer/trunk		React_OAuthServer-trunk
> 
> modules - ^/react_v2/modules/React_AccessControl_RsqlRules/trunk React_AccessControl_RsqlRules-trunk
> ^/react_v2/modules/React_Framework/branches/1.3		React_Framework-1.3

The log shows the following error:

2010-12-30 08:57:49,003 [Thread-11524] WARN  SVN              - svn: 'React_ModelBuilder-1.3' is not under version control
2010-12-30 08:57:49,012 [Thread-11522] ERROR SVN              - Error executing svn log command svn log --non-interactive --xml -v -r {2010-12-29T14:31:15Z}:{2010-12-30T07:57:48Z} React_ModelBuilder-1.3
org.jdom.input.JDOMParseException: Error on line 3: XML document structures must start and end within the same entity.
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:468)
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:851)
        at net.sourceforge.cruisecontrol.sourcecontrols.SVN$SVNLogXMLParser.parse(SVN.java:541)
        at net.sourceforge.cruisecontrol.sourcecontrols.SVN$SVNLogXMLParser.parseAndFilter(SVN.java:528)
        at net.sourceforge.cruisecontrol.sourcecontrols.SVN.execHistoryCommand(SVN.java:449)
        at net.sourceforge.cruisecontrol.sourcecontrols.SVN.getModifications(SVN.java:258)
        at net.sourceforge.cruisecontrol.ModificationSet.retrieveModificationsAsElement(ModificationSet.java:266)
        at net.sourceforge.cruisecontrol.Project.getModifications(Project.java:427)
        at net.sourceforge.cruisecontrol.Project.build(Project.java:199)
        at net.sourceforge.cruisecontrol.Project.execute(Project.java:148)
        at net.sourceforge.cruisecontrol.ProjectConfig.execute(ProjectConfig.java:408)
        at net.sourceforge.cruisecontrol.ProjectWrapper.run(ProjectWrapper.java:69)
        at java.lang.Thread.run(Thread.java:636)

There seems to be more problems with the code, especially in getModifications(); which attempts to use the svnUrl for the svn-log command. However, this would require support for the special syntaxes svn-1.5 supports (as described @ http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html). Therefore I propose using the local path for svn-log; which should be easier to implement. My (untested) suggestion is as follows:

$ diff SVN.java.r4349 SVN.java
239,240c239
<                     final String path = directory + "/" + external[0];
<                     final String svnURL = external[1];
---
>                     final String path = directory + "/" + external[1];
242c241
<                         command = buildHistoryCommand(startRevision, endRevision, svnURL);
---
>                         command = buildHistoryCommand(startRevision, endRevision, path);
245c244
<                         command = buildHistoryCommand(startRevision, endRevision, svnURL);
---
>                         command = buildHistoryCommand(startRevision, endRevision, path);
432c431
<                 // split contains: [externalPath, externalSvnURL]
---
>                 // split contains: [externalSvnURL, externalPath]


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl