Due to a complex structure in a SVN repository, some external files are not correctly retrieved from the repository. As changing the repository structure is not an option, I have developed a script that iterates through the externals and retrieves them 'by hand' if needed (thanks to 'svn export'). To detect if this operation is indeed needed, I execute 'svn info', assuming that it will return different from 0 if the file does not exist, or it is not versioned. That was indeed the behavior obtained in host1 (SVN Client 1.6.17):
# Initially, the directory is empty host1$ ls host1$ svn update Fetching external item into 'main.rbf' svn: warning: '<REMOTE_SVN_LOCATION1>' is not the same repository as '<REMOTE_SVN_LOCATION2>' At revision 18413. # Although we do the update, the external item is not fetched, # as it is a single file coming from a different repository # (known problem) host1$ ls # The file is not present, and SVN info acts accordingly host1$ svn info main.rbf main.rbf: (Not a versioned resource) svn: A problem occurred; see other errors for details # If we force the SVN export host1$ svn export <REMOTE_SVN_LOCATION1> main.rbf A main.rbf Export complete. host1$ ls main.rbf # then SVN info detects it and acts accordingly host1$ svn info main.rbf main.rbf: (Not a versioned resource) svn: A problem occurred; see other errors for details host1$
In host2, (SVN Client 1.6.11), the behaviour of 'SVN info' is completely different: no matter if the file is there (from a previous export) or not, the answer is:
# Directory is empty host2$ ls host2$ svn info Path: . URL: <REMOTE_LOCATION> Repository Root: ... Repository UUID: ... Revision: 18413 Node Kind: directory Schedule: normal Last Changed Author: ... Last Changed Rev: 18326 Last Changed Date: ... host2$
Is there any reason to explain this inconsistent behavior? How can I detect this unversioned file in host2 ?