A causa di una struttura complessa in un repository SVN, alcuni file esterni non vengono recuperati correttamente dal repository. Dato che cambiare la struttura del repository non è un'opzione, ho sviluppato uno script che scorre attraverso gli esterni e li recupera "a mano" se necessario (grazie a "svn export"). Per rilevare se questa operazione è effettivamente necessaria, eseguo 'svn info', supponendo che restituirà un valore diverso da 0 se il file non esiste o non è aggiornato. Questo era effettivamente il comportamento ottenuto in host1 (client SVN 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, (client SVN 1.6.11), il comportamento di "informazioni SVN" è completamente diverso: non importa se il file è presente (da una precedente esportazione) o meno, la risposta è:
# 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$
C'è qualche motivo per spiegare questo comportamento incoerente? Come posso rilevare questo file non verificato in host2?