la carga de subversión falla con "no dicha revisión"

Estoy tratando de aprender cómo migrar un repositorio de Subversion y me encuentro con un problema que no tiene sentido para mí. Solía svndumpfilterdividir un subproyecto y eliminé algunos prefijos de ruta. Varios cientos de confirmaciones ahora se importan correctamente, pero obtengo el siguiente error:

<<< 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, así que voy al archivo de volcado para ver las revisiones 19190 y 19098. En primer lugar, la revisión 19098 sí existe en el archivo de volcado y se importó sin problemas. La revisión 19190 es una fusión. En 19190, aquí está la información del último archivo, que parece estar causando el 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 revisión 19100 NO existe en este archivo filtrado. Pero el error no se refiere a 19100, ¡se refiere a 19098!

¿Qué debo hacer para cargar este archivo?

¡Gracias!

He hecho este tipo de división muchas veces. Creo que todo depende de cómo use el filtro y qué procesamiento realice en el archivo de volcado posterior. Personalmente, también tuve que cambiar el usuario svn, junto a la ruta del proyecto, y renumerar las revisiones. Para que pueda ver lo que se puede hacer, aquí hay una parte relevante de mi script.

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

Lo que sucede allí es que primero, filtro lo que necesito, descarto las revisiones vacías por razones obvias y las vuelvo a numerar. Esto da buenas revisiones ordenadas. Luego dejo caer la ruta raíz del proyecto que en mi caso era en forma de grupo / cliente porque en el nuevo repositorio no tiene sentido (en cambio, el repositorio en sí es grupo / cliente en el disco): estos son los primeros 2 sed

A continuación, elimino la importación de directorios no nombrados, uno resultante de los 2 seds anteriores para el directorio del grupo y luego uno para el directorio del grupo / cliente que se agrega.

Finalmente, pedí al autor que lo cambiara por uno nuevo. Este también fue un poco complicado ya que requería actualizar la longitud de la definición de propiedad.

Luego lo cargo y reparo los permisos del sistema de archivos. Tenga en cuenta los 2 chowns comentados para apache, en algunos casos lo necesitará. Finalmente terminé agregando apache al grupo svn.

Ahora, nunca tuve fusiones en mi repositorio SVN, así que nunca tuve que lidiar con ellos para la división. En su caso, me imagino que lo que sucede es que la ruta de revisión de origen no se importa y es por eso que no la encuentra a pesar de que el error se queja en la revisión en sí). La regla general en el archivo de importación svn es que todo lo que se hace referencia en un punto ya debe haber sido importado antes de que se haga referencia. Por lo tanto, es posible que haya filtrado algo que no debería, aunque lo desee, o que no haya actualizado el archivo de volcado correctamente para reflejar cualquier otro cambio que haya realizado.

Si proporciona la estructura relevante de su repositorio original, incluida la ruta de origen combinada, más sus llamadas con parámetros, es posible que pueda decirle lo que perdió. Mi dinero está en la fuente de la fusión.

He usado una gran herramienta svndumpsanitizer . El problema es que la estructura del repositorio de subversión es demasiado complicada. Cuando svndumpfilter está en la revisión 10, no tiene forma de saber si un nodo que el usuario quiere descartar, se moverá a una posición que desea mantener en la revisión 113. Por lo tanto, hace lo único que puede hacer: descarta el nodo , y en la revisión 113 falla porque ya ha descartado los datos que resultaron necesarios.

Svndumpsanitizer funciona de manera diferente. Escanea los nodos varias veces para descubrir qué nodos deberían mantenerse realmente. Después de determinar qué nodos mantener, solo escribe estos nodos en el archivo. Finalmente, si es necesario, agrega una confirmación que elimina todos los nodos no deseados que tuvieron que mantenerse para no romper el repositorio.