il carico di sovversione non riesce con "nessuna revisione di questo tipo"

Sto cercando di imparare come migrare un repository Subversion e sto incontrando un problema che non ha senso per me. Ho usato svndumpfilterper dividere un sottoprogetto e ho rimosso alcuni prefissi di percorso. Diverse centinaia di commit ora importano correttamente, ma poi ricevo il seguente errore:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, così vado in file di dump di guardare revisioni 19190 e 19098. Prima di tutto, la revisione 19098 fa esistere nel file di dump ed è stato importato senza un problema. La revisione 19190 è una fusione. Entro 19190, ecco le informazioni dell'ultimo file, che sembrano causare il problema:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Confusamente, la revisione 19100 NON esiste in questo file filtrato. Ma l'errore non si riferisce al 19100, si riferisce al 19098!

Cosa devo fare per caricare questo file?

Grazie!

Ho fatto questo tipo di divisione molte volte. Penso che tutto dipenda da come usi il filtro e da quale elaborazione fai sul file di dump in seguito. Personalmente, ho anche dovuto cambiare l'utente svn, accanto al percorso del progetto, e rinumerare le revisioni. Solo così puoi vedere cosa si può fare, ecco la parte rilevante della mia sceneggiatura.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

Quello che succede è che per prima cosa, filtrerò ciò di cui ho bisogno, lascio cadere le revisioni vuote per ovvie ragioni e le rinumero. Questo dà piacevoli revisioni ordinate. Poi lascio cadere il percorso di root del progetto che nel mio caso era sotto forma di gruppo / cliente perché nel nuovo repository non ha senso (invece il repository stesso è gruppo / cliente su disco) - questo è il primo 2 sed

Di seguito, rimuovo l'importazione di directory senza nome, una risultante dalle precedenti 2 sed per la directory di gruppo e quindi una per l'aggiunta della directory di gruppo / cliente.

infine, ho sed l'autore per cambiarlo in uno nuovo. Anche questo è stato un po 'complicato in quanto ha richiesto l'aggiornamento della lunghezza della definizione della proprietà.

Quindi lo carico e aggiorno le autorizzazioni del filesystem. Nota i 2 chown commentati per apache, in alcuni casi ne avrai bisogno. Alla fine ho finito per aggiungere apache al gruppo svn.

Ora, non ho mai avuto fusioni nei miei repository SVN, quindi non ho mai avuto a che fare con loro per la divisione. Nel tuo caso, immaginerei che ciò che accade è che il percorso di revisione della fonte non viene importato ed è per questo che non lo trova anche se l'errore si lamenta della revisione stessa). La regola empirica nel file di importazione svn è che tutto ciò a cui viene fatto riferimento in un punto deve essere già stato importato prima di essere indirizzato. Quindi potresti aver filtrato qualcosa che non dovresti, anche se lo desideri, o non aver aggiornato correttamente il file di dump per riflettere qualsiasi altra modifica che hai apportato.

Se si fornisce la struttura dedicata del vostro repo originale, compreso il percorso di origine unito, più le chiamate con parametri, io possa essere in grado di tel voi cosa vi siete persi. I miei soldi sono sulla fonte della fusione.

Ho usato un ottimo strumento svndumpsanitizer . Il problema è che la struttura del repository di sovversione è troppo complicata. Quando svndumpfilter è alla revisione 10, non ha modo di sapere se un nodo che l'utente vuole scartare, verrà spostato in una posizione che desidera mantenere nella revisione 113. Quindi fa l'unica cosa che può fare: scarta il nodo e alla revisione 113 emerge perché ha già scartato i dati che risulta necessari.

Svndumpsanitizer funziona in modo diverso. Esegue la scansione dei nodi più volte per scoprire quali nodi devono essere effettivamente mantenuti. Dopo aver determinato quali nodi mantenere, scrive solo questi nodi nel file di output. Infine, se necessario, aggiunge un commit che elimina tutti i nodi indesiderati che dovevano essere conservati per non interrompere il repository.