Guest?
 
Project
SVNKit
Priority
Normal
Type
Bug
State
Fixed
Assignee
Alexander Kitaev
Subsystem
Unknown subsystem
Affected versions
1.7.0
Fix versions
No Fix versions
Fixed in build
No Fixed in build
  • Created by   Dominik Stadler
    12 months ago (03 May 2012 22:34)
  • Updated by   Dmitry Pavlenko
    12 months ago (04 May 2012 18:10)
0
Issue is visible to: All Users
  The issue is visible to the selected user group only
According to documentation, SVNLogClient.doList() calls the provided callback once for each sub-entry in a SVN-URL, however when I create a test-case which verifies this, I only get the revision number of the url back.

Version is 1.7.4, test case is as follows:

package org.tmatesoft.svn.test;

import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;

import java.util.ArrayList;
import java.util.List;

import org.junit.Test;
import org.tmatesoft.svn.core.ISVNDirEntryHandler;
import org.tmatesoft.svn.core.SVNDirEntry;
import org.tmatesoft.svn.core.SVNException;
import org.tmatesoft.svn.core.SVNURL;
import org.tmatesoft.svn.core.auth.ISVNAuthenticationManager;
import org.tmatesoft.svn.core.wc.SVNLogClient;
import org.tmatesoft.svn.core.wc.SVNRevision;

public class SVNLogClientTest {
	@Test
	public void testListSubversionTagsParameter() throws Exception {
		// read tags from a repository
		String tagsDir = "http://svn.codehaus.org/sxc";

		SimpleSVNDirEntryHandler dirEntryHandler = new SimpleSVNDirEntryHandler();
		List<String> dirs = new ArrayList<String>();

		SVNURL repoURL = SVNURL.parseURIDecoded(tagsDir);

		ISVNAuthenticationManager authManager = null;
		SVNLogClient logClient = new SVNLogClient(authManager, null);

		System.out.println("Listing sub-svn-tags via " + repoURL);
		logClient.doList(repoURL, SVNRevision.HEAD, SVNRevision.HEAD, false,
				false, dirEntryHandler);
		dirs = dirEntryHandler.getDirs();

		System.out.println("Had " + dirs);

		assertNotNull(dirs);

		assertTrue("Had: " + dirs, dirs.size() > 0);
		assertTrue("Had: " + dirs, dirs.contains("sxc-0.7"));
		assertTrue("Had: " + dirs, dirs.contains("sxc-0.7.1"));
		assertTrue("Had: " + dirs, dirs.contains("trunk"));
	}

	public class SimpleSVNDirEntryHandler implements ISVNDirEntryHandler {
		private final List<SVNDirEntry> dirs = new ArrayList<SVNDirEntry>();

		public List<String> getDirs() {
			List<String> sortedDirs = new ArrayList<String>();
			for (SVNDirEntry dirEntry : dirs) {
				sortedDirs.add(dirEntry.getName());
			}

			return sortedDirs;
		}

		public void handleDirEntry(SVNDirEntry dirEntry) throws SVNException {
			dirs.add(dirEntry);
		}
	}
}



it fails with

java.lang.AssertionError: Had: [127]
java.lang.AssertionError: Had: [127]
 at org.junit.Assert.fail(Assert.java:91)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at org.tmatesoft.svn.test.SVNLogClientTest.testListSubversionTagsParameter(SVNLogClientTest.java:42)
Comments (3)
 
History
 
Linked Issues (?)
 
TeamCity Changes (0)
 
Dominik Stadler
  Dominik Stadler
03 May 2012 22:53
12 months ago
I think I found out, it is because of "recursive=false" in the call to doList(). Internally it transforms this into SVNDepth.FILES, which does not list any sub-directory.

I expected to have it would resolve to SVNDepth.IMMEDIATES here and this is also what the Jenkins Subversion plugin expects, either this is a change in behavior of svnkit 1.7.x, or the related functionality in Jenkins was broken for a long time, see https://issues.jenkins-ci.org/browse/JENKINS-11933?focusedCommentId=162147&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-162147 for details.
Dominik Stadler
  Dominik Stadler
03 May 2012 22:58
12 months ago
To add further to this, in 1.3.7 we have the following:

{code}
public void doList(File path, SVNRevision pegRevision, SVNRevision revision, boolean fetchLocks, boolean recursive, ISVNDirEntryHandler handler) throws SVNException {
doList(path, pegRevision, revision, fetchLocks, recursive ? SVNDepth.INFINITY : SVNDepth.IMMEDIATES, SVNDirEntry.DIRENT_ALL, handler);
}
{quote}

So in 1.3.7 SVNDepth.IMMEDIATES was used, now SVNDepth.FILES is used, so this is a change in behavior between 1.3.7 and 1.7.x.
Dmitry Pavlenko
  Dmitry Pavlenko
04 May 2012 18:10
12 months ago
Hello Dominik,
Thank you for finding an important bug. The revision was reported instead of "" entry (that represents doList target itself). I've fixed the problem in the trunk. In about 2-3 days we'll issue an intermediate release with the fix included.

What about "recursive" problem: it might be. Anyway "recursive" parameter is deprecated, specify SVNDepth explicitly instead to avoid ambiguity.
Related Changes
Resolved Date
12 months ago (04 May 2012 18:10)
State
SubmittedFixed
Apply Command

Command Preview: