git-svn: en línea en la nube

PROGRAMA:

NOMBRE

git-svn: operación bidireccional entre un repositorio de Subversion y Git

SINOPSIS

git svn [opciones] [argumentos]

DESCRIPCIÓN

git svn es un conducto simple para conjuntos de cambios entre Subversion y Git. Proporciona un
Flujo bidireccional de cambios entre una Subversion y un repositorio Git.

git svn puede rastrear un repositorio estándar de Subversion, siguiendo las normas comunes
diseño "tronco / ramas / etiquetas", con la opción --stdlayout. También puede seguir ramas y
etiquetas en cualquier diseño con las opciones -T / -t / -b (consulte las opciones para init a continuación, y también el
clonar mando).

Una vez que se rastrea un repositorio de Subversion (con cualquiera de los métodos anteriores), el repositorio de Git
se puede actualizar desde Subversion mediante el ha podido recuperar comando y Subversion actualizado desde Git por el
comprometerse mando.

COMANDOS

init
Inicializa un repositorio de Git vacío con directorios de metadatos adicionales para git svn.
La URL de Subversion se puede especificar como un argumento de línea de comandos o como una URL completa.
argumentos a -T / -t / -b. Opcionalmente, se puede especificar el directorio de destino en el que operar
como segundo argumento. Normalmente, este comando inicializa el directorio actual.

-T , --trunk = , -t , --tags = ,
-B , --ramas = , -s, --stdlayout
Estas son opciones de línea de comandos opcionales para init. Cada una de estas banderas puede apuntar a
una ruta de repositorio relativa (--tags = proyecto / etiquetas) o una URL completa
(--tags = https: //foo.org/project/tags). Puede especificar más de una: etiquetas y / o
- opciones de ramas, en caso de que su repositorio de Subversion coloque etiquetas o ramas
bajo múltiples caminos. La opción --stdlayout es una forma abreviada de configurar
tronco, etiquetas, ramas como rutas relativas, que es el valor predeterminado de Subversion. Si alguna
de las otras opciones también se dan, tienen prioridad.

--no-metadatos
Seleccione las sin metadatos opción en la configuración [svn-remote]. Esta opción no es
recomendado, lea el svn.noMetadatos sección de esta página de manual antes de usar
esta opción.

--use-svm-props
Seleccione las usarSvmProps opción en la configuración [svn-remote].

--use-svnsync-props
Seleccione las usarSvnsyncProps opción en la configuración [svn-remote].

--rewrite-root =
Seleccione las reescribir raíz opción en la configuración [svn-remote].

--rewrite-uuid =
Seleccione las reescribirUUID opción en la configuración [svn-remote].

--username =
Para los transportes para los que SVN maneja la autenticación (http, https y svn simple),
especifique el nombre de usuario. Para otros transportes (por ejemplo, svn + ssh: //), debe incluir
el nombre de usuario en la URL, por ejemplo, svn + ssh: //[email protected]/proyecto

--prefijo =
Esto permite especificar un prefijo que se antepone a los nombres de los controles remotos si
se especifican tronco / ramas / etiquetas. El prefijo no incluye automáticamente un
barra al final, así que asegúrese de incluir una en el argumento si eso es lo que
querer. Si se especifica --branches / -b, el prefijo debe incluir una barra inclinada al final.
En cualquier caso, se recomienda encarecidamente establecer un prefijo (con una barra al final), ya que
sus referencias de seguimiento de SVN se ubicarán en "refs / remotes / $ prefix /", lo cual is
compatible con Git's propia seguimiento remoto ref. diseño (refs / remotos / $ remoto /).
Establecer un prefijo también es útil si desea realizar un seguimiento de varios proyectos que comparten
un repositorio común. De forma predeterminada, el prefijo se establece en origen/.

Nota
Antes de Git v2.0, el prefijo predeterminado era "" (sin prefijo). Esto quiere decir eso
Las referencias de seguimiento de SVN se colocaron en "refs / remotes / *", lo cual es incompatible con cómo
Las propias referencias de seguimiento remoto de Git están organizadas. Si aun quieres lo viejo
predeterminado, puede obtenerlo pasando --prefix "" en la línea de comando
(--prefix = "" puede no funcionar si el Getopt :: Long de Perl es <v2.37).

--ignore -path =
Cuando pasa a init or clonar esta expresión regular se conservará como una configuración
clave. Ver ha podido recuperar para una descripción de - ignorar-caminos.

--include-caminos =
Cuando pasa a init or clonar esta expresión regular se conservará como una configuración
clave. Ver ha podido recuperar para una descripción de --incluir-caminos.

--no-minimizar-url
Al rastrear varios directorios (usando --stdlayout, --branches o --tags
opciones), git svn intentará conectarse a la raíz (o al nivel más alto permitido)
del repositorio de Subversion. Este valor predeterminado permite un mejor seguimiento del historial si
proyectos completos se mueven dentro de un repositorio, pero pueden causar problemas en
repositorios donde existen restricciones de acceso de lectura. Paso
--no-minimizar-url permitirá que git svn acepte las URL tal como están sin intentar
conectarse a un directorio de nivel superior. Esta opción está desactivada de forma predeterminada cuando solo una
Se realiza un seguimiento de la URL / rama (no serviría de mucho).

ha podido recuperar
Obtenga las revisiones no obtenidas del control remoto de Subversion que estamos rastreando. El nombre de
La sección [svn-remote "..."] en el archivo $ GIT_DIR / config puede especificarse como opcional
argumento de la línea de comandos.

Esto actualiza automáticamente el rev_map si es necesario (consulte $ GIT_DIR / svn / ** /. Rev_map. * in
la sección ARCHIVOS a continuación para obtener más detalles).

--hora local
Almacene las horas de confirmación de Git en la zona horaria local en lugar de UTC. Esto hace git log
(incluso sin --date = local) muestra las mismas horas que el registro svn en el local
zona horaria.

Esto no interfiere con la interoperabilidad con el repositorio de Subversion que
clonado desde, pero si desea que su repositorio local de Git pueda
interoperar con el repositorio local de Git de otra persona, o no use esto
opción o ambos deberían usarlo en la misma zona horaria local.

--padre
Obtener solo del padre SVN del HEAD actual.

--ignore -path =
Esto permite especificar una expresión regular de Perl que provocará la omisión de
todas las rutas coincidentes desde el pago de SVN. los - ignorar-caminos la opción debe coincidir
para cada ha podido recuperar (incluidas las recuperaciones automáticas debido a clonar, comprometerse, rebase, Etc)
en un repositorio determinado.

clave de configuración: svn-remote. .ignore-rutas

Si se establece la clave de configuración de ignorar rutas, y la opción de línea de comandos también
dado, se utilizarán ambas expresiones regulares.

Ejemplos:

Omitir el directorio "doc *" para cada búsqueda

--ignore -path = "^ doc"

Omitir "ramas" y "etiquetas" de los directorios de primer nivel

--ignore -path = "^ [^ /] + / (?: ramas | etiquetas)"

--include-caminos =
Esto permite especificar una expresión regular de Perl que provocará la inclusión
de solo las rutas coincidentes desde el pago de SVN. los --incluir-caminos la opción debería
partido para cada ha podido recuperar (incluidas las recuperaciones automáticas debido a clonar, comprometerse, rebase,
etc.) en un repositorio determinado. - ignorar-caminos tiene prioridad sobre --incluir-caminos.

clave de configuración: svn-remote. .incluir-rutas

--log-window-size =
Ir a buscar registrar entradas por solicitud al escanear el historial de Subversion. El valor predeterminado es
100. Para repositorios de Subversion muy grandes, es posible que se necesiten valores mayores para
clonar/ha podido recuperar para completar en un tiempo razonable. Pero los valores demasiado grandes pueden conducir a
mayor uso de memoria y tiempos de espera de solicitud.

clonar
Ron init y ha podido recuperar. Automáticamente creará un directorio basado en el nombre base de
la URL que se le pasó; o si se pasa un segundo argumento; creará un directorio
y trabajar dentro de eso. Acepta todos los argumentos que el init y ha podido recuperar comandos
aceptar; con la excepción de --buscar-todo y --padre. Después de clonar un repositorio,
los ha podido recuperar El comando podrá actualizar las revisiones sin afectar el árbol de trabajo;
y la rebase comando podrá actualizar el árbol de trabajo con la última
cambios.

--preserve-vacíos-dirs
Cree un archivo de marcador de posición en el repositorio local de Git para cada directorio vacío
obtenido de Subversion. Esto incluye directorios que se vacían al eliminar
todas las entradas en el repositorio de Subversion (pero no el directorio en sí). los
Los archivos de marcador de posición también se rastrean y eliminan cuando ya no son necesarios.

--placeholder-filename =
Establezca el nombre de los archivos de marcador de posición creados por --preserve-empty-dirs. Defecto:
".gitignore"

rebase
Esto obtiene las revisiones del padre SVN del HEAD actual y vuelve a basar el actual
(no comprometido con SVN) trabaja en su contra.

Esto funciona de manera similar a svn update o git recogida excepto que conserva la historia lineal
con git rebase en lugar de git unir para facilitar el compromiso con git svn.

Esto acepta todas las opciones que git svn ha podido recuperar y git rebase aceptar. Sin embargo,
--buscar-todo solo recupera el [svn-remote] actual, y no todos los [svn-remote]
definiciones.

Como git rebase; esto requiere que el árbol de trabajo esté limpio y no tenga ningún compromiso
cambios.

Esto actualiza automáticamente el rev_map si es necesario (consulte $ GIT_DIR / svn / ** /. Rev_map. * in
la sección ARCHIVOS a continuación para obtener más detalles).

-l, --local
No buscar de forma remota; solo corre git rebase contra el último compromiso obtenido de
el SVN aguas arriba.

comprometerse
Confirme cada diff de la rama actual directamente en el repositorio SVN, y luego
rebase o reset (dependiendo de si hay o no una diferencia entre SVN y head).
Esto creará una revisión en SVN para cada confirmación en Git.

Cuando un nombre de rama de Git opcional (o un nombre de objeto de confirmación de Git) se especifica como un
argumento, el subcomando funciona en la rama especificada, no en la rama actual.

El uso del sitio web de comprometerse se prefiere a conjunto-árbol (abajo).

--no-rebase
Después de comprometerse, no reajuste ni reinicie.

--commit-url
Comprometerse con esta URL SVN (la ruta completa). Esto tiene la intención de permitir git svn
repositorios creados con un método de transporte (por ejemplo, svn: // o http: // para
lectura anónima) para ser reutilizado si posteriormente se le da acceso a un usuario a un
método de transporte (por ejemplo, svn + ssh: // o https: //) para confirmar.

clave de configuración: svn-remote. .commiturl
clave de configuración: svn.commiturl (sobrescribe todos los archivos svn-remote. .commiturl opciones)

Tenga en cuenta que la URL SVN de la clave de configuración commiturl incluye la rama SVN. Si tu
prefiero establecer la URL de confirmación para un uso completo del repositorio SVN
svn-remote. .pushurl en su lugar.

Se desaconseja encarecidamente utilizar esta opción para cualquier otro propósito (no preguntes).

--mergeinfo =
Agregue la información de combinación dada durante el dcommit (por ejemplo,
--mergeinfo = "/ ramas / foo: 1-10"). Todas las versiones del servidor svn pueden almacenar esto
información (como una propiedad), y los clientes svn a partir de la versión 1.5 pueden hacer
uso de ella. Para especificar información de combinación de varias ramas, use un solo espacio
carácter entre las ramas (--mergeinfo = "/ ramas / foo: 1-10
/ ramas / barra: 3,5-6,8 ")

clave de configuración: svn.pushmergeinfo

Esta opción hará que git-svn intente completar automáticamente el
svn: propiedad mergeinfo en el repositorio SVN cuando sea posible. Actualmente, esto puede
solo se puede hacer cuando dcommitting non-fast-forward fusiona donde todos los padres excepto el
primero ya se han introducido en SVN.

--interactivo
Pídale al usuario que confirme que realmente se debe enviar un conjunto de parches a SVN. Para cada
parche, uno puede responder "sí" (aceptar este parche), "no" (descartar este parche), "todos"
(aceptar todos los parches), o "salir".

git svn comprometerse regresa inmediatamente si la respuesta es "no" o "salir", sin
comprometiendo cualquier cosa con SVN.

biblioteca
Cree una rama en el repositorio de SVN.

-m, --mensaje
Permite especificar el mensaje de confirmación.

-t, --etiqueta
Cree una etiqueta utilizando tags_subdir en lugar del branch_subdir especificado
durante git svn init.

-D , --destino =
Si se le dio más de una opción --branches (o --tags) al init or clonar
comando, debe proporcionar la ubicación de la rama (o etiqueta) que desea crear
en el repositorio SVN. especifica qué ruta usar para crear la rama o
etiqueta y debe coincidir con el patrón en el lado izquierdo de uno de los configurados
ramas o etiquetas refspecs. Puedes ver estas refspecs con los comandos

git config --get-all svn-remote. .sucursales
git config --get-all svn-remote. .etiquetas

dónde es el nombre del repositorio SVN según lo especificado por la opción -R para
init (o "svn" por defecto).

--nombre de usuario
Especifique el nombre de usuario de SVN para realizar la confirmación. Esta opción anula la
nombre de usuario propiedad de configuración.

--commit-url
Utilice la URL especificada para conectarse al repositorio de Subversion de destino. Este es
útil en los casos en que el repositorio SVN de origen es de solo lectura. Esta opción
anula la propiedad de configuración confirmar.

git config --get-all svn-remote. .commiturl

--padres
Cree carpetas principales. Este parámetro es equivalente al parámetro --parents on
svn cp y es útil para diseños de repositorios no estándar.

etiqueta
Cree una etiqueta en el repositorio de SVN. Esta es una abreviatura de biblioteca -t.

log
Esto debería facilitar la búsqueda de mensajes de registro de svn cuando los usuarios de svn se refieren a
-r / - números de revisión.

Se admiten las siguientes funciones de 'svn log':

-r [: ], --revision = [: ]
es compatible, los argumentos no numéricos no son: HEAD, NEXT, BASE, PREV, etc ...

-v, --detallado
no es completamente compatible con la salida --verbose en svn log, pero
razonablemente cerca.

--limit =
NO es lo mismo que --max-count, no cuenta las confirmaciones fusionadas / excluidas

- incremental
apoyadas

Nuevas características:

--mostrar-compromiso
muestra el compromiso de Git sha1, también

--una línea
nuestra versión de --pretty = oneline

Nota
SVN en sí solo almacena las horas en UTC y nada más. El cliente svn regular
convierte la hora UTC a la hora local (o según el entorno TZ =). Esta
El comando tiene el mismo comportamiento.
Cualquier otro argumento se pasa directamente a git log

culpa
Muestre qué revisión y autor modificó por última vez cada línea de un archivo. La salida de este
el modo es compatible con el formato con la salida de 'svn blame' por defecto. Como el SVN
comando de culpa, los cambios locales no confirmados en el árbol de trabajo se ignoran; la versión
del archivo en la revisión HEAD está anotado. Los argumentos desconocidos se pasan directamente
a git culpa.

--formato de git
Producir salida en el mismo formato que git culpa, pero con números de revisión SVN
en lugar de Git commit hashes. En este modo, los cambios que no se han realizado
SVN (incluidas las ediciones de la copia de trabajo local) se muestran como revisión 0.

buscar-rev
Cuando se le da un número de revisión SVN del formulario rN, devuelve la confirmación de Git correspondiente
hash (esto puede ser seguido opcionalmente por un árbol-ish para especificar qué rama debe ser
buscado). Cuando se le da un árbol, devuelve el número de revisión SVN correspondiente.

-B, --antes
No requiera una coincidencia exacta si se le da una revisión SVN, en su lugar busque la confirmación
correspondiente al estado del repositorio SVN (en la rama actual) en el
revisión especificada.

-A, --después
No requiera una coincidencia exacta si se le da una revisión SVN; si no hay un exacto
match devuelve la coincidencia más cercana buscando hacia adelante en el historial.

conjunto-árbol
Deberías considerar usar comprometerse en lugar de este comando. Confirmar compromiso especificado o
objetos de árbol a SVN. Esto depende de que sus datos de recuperación importados estén actualizados. Esta
no hace absolutamente ningún intento de parchear cuando se compromete con SVN, simplemente
sobrescribe los archivos con los especificados en el árbol o se confirma. Se supone que toda fusión
han tenido lugar independientemente de git svn funciones.

crear-ignorar
Encuentra recursivamente la propiedad svn: ignore en directorios y crea coincidencias
Archivos .gitignore. Los archivos resultantes se preparan para su confirmación, pero no
comprometido. Utilice -r / - revisión para referirse a una revisión específica.

mostrar-ignorar
Busca y enumera de forma recursiva la propiedad svn: ignore en los directorios. La salida es
adecuado para agregar al archivo $ GIT_DIR / info / exclude.

mkdirs
Intentos de recrear directorios vacíos que el núcleo de Git no puede rastrear en función de la información
en $ GIT_DIR / svn / Archivos /unhandled.log. Los directorios vacíos son automáticamente
recreado al usar "git svn clone" y "git svn rebase", por lo que "mkdirs" está destinado a
usar después de comandos como "git checkout" o "git reset". (Ver el
svn-remote. Opción de archivo de configuración .automkdirs para obtener más información).

cometer-diferencia
Confirma la diferencia de dos argumentos en forma de árbol desde la línea de comandos. Este comando hace
no confíe en estar dentro de un repositorio git svn init-ed. Este comando toma tres
argumentos, (a) el árbol original contra el que comparar, (b) el resultado del nuevo árbol, (c) la URL
del repositorio de Subversion de destino. El argumento final (URL) puede omitirse si
están trabajando desde un git svn-repositorio consciente (que se ha iniciado con git svn). La
-r Se requiere la opción para esto.

info
Muestra información sobre un archivo o directorio similar a lo que proporciona 'svn info'. Lo hace
actualmente no es compatible con un argumento de revisión -r / -. Use la opción --url para generar solo
el valor de la URL: campo.

proplista
Enumera las propiedades almacenadas en el repositorio de Subversion sobre un archivo o
directorio. Use -r / - revision para referirse a una revisión específica de Subversion.

propósito
Obtiene la propiedad de Subversion proporcionada como primer argumento, para un archivo. Especifico
la revisión se puede especificar con -r / - revisión.

mostrar-externos
Muestra los externos de Subversion. Utilice -r / - revisión para especificar una revisión específica.

gc
Comprimir $ GIT_DIR / svn / /unhandled.log archivos y eliminar
$ GIT_DIR / svn / / archivos de índice.

reajustar
Deshace los efectos de ha podido recuperar volver a la revisión especificada. Esto te permite
re-ha podido recuperar una revisión SVN. Normalmente, el contenido de una revisión SVN nunca debería cambiar
y reajustar no debería ser necesario. Sin embargo, si cambian los permisos de SVN o si modifica
su opción --ignore -path, una ha podido recuperar puede fallar con "no encontrado en la confirmación" (el archivo no
previamente visible) o "falta de coincidencia en la suma de comprobación" (se perdió una modificación). Si el problema
el archivo no se puede ignorar para siempre (con --ignore-routes) la única forma de reparar el repositorio
es utilizar reajustar.

Solo se cambian rev_map y refs / remotes / git-svn (ver $ GIT_DIR / svn / ** /. Rev_map. *
en la sección ARCHIVOS a continuación para obtener más detalles). Seguir reajustar con ha podido recuperar y luego git reajustar
or git rebase para mover las ramas locales al nuevo árbol.

-r , --revision =
Especifique la revisión más reciente para conservar. Todas las revisiones posteriores se descartan.

-p, --padre
Descarte también la revisión especificada, conservando el padre más cercano en su lugar.

Ejemplo:
Suponga que tiene cambios locales en "master", pero necesita volver a buscar "r2".

r1 --- r2 --- r3 controles remotos / git-svn
\
Maestro A --- B

Solucione el problema de permisos de ignorar rutas o SVN que causaba que "r2" estuviera incompleto
en primer lugar. Luego:

git svn restablecer -r2 -p
git svn buscar

r1 --- r2 '- r3' controles remotos / git-svn
\
r2 --- r3 --- A --- B maestro

Luego arregla "maestro" con git rebase. No utilice git unir o tu historia no
ser compatible con un futuro comprometerse!

git rebase --en controles remotos / git-svn A ^ master

r1 --- r2 '- r3' controles remotos / git-svn
\
Maestro A '- B'

OPCIONES

--shared [= (falso | verdadero | umask | grupo | todos | mundo | todos)], --template =
Solo se usa con el init mando. Estos se pasan directamente a git init.

-r , --revisión
Usado con el ha podido recuperar mando.

Esto permite admitir rangos de revisión para historial parcial / cauterizado. $ NUMBER,
$ NUMBER1: $ NUMBER2 (rangos numéricos), $ NUMBER: HEAD y BASE: $ NUMBER son todos compatibles.

Esto puede permitirle hacer espejos parciales al ejecutar fetch; pero generalmente no es
recomendado porque el historial se omitirá y se perderá.

-, --stdin
Solo se usa con el conjunto-árbol mando.

Lea una lista de confirmaciones de stdin y confirme en orden inverso. Solo el líder
sha1 se lee en cada línea, por lo que git lista de revoluciones --pretty = en línea se puede utilizar la salida.

--rmdir
Solo se usa con el comprometerse, conjunto-árbol y cometer-diferencia comandos.

Elimine directorios del árbol SVN si no quedan archivos. SVN puede
versión de directorios vacíos, y no se eliminan de forma predeterminada si no hay archivos
dejado en ellos. Git no puede versionar directorios vacíos. Habilitar esta bandera hará que el
comprometerse a que SVN actúe como Git.

clave de configuración: svn.rmdir

-e, --edit
Solo se usa con el comprometerse, conjunto-árbol y cometer-diferencia comandos.

Edite el mensaje de confirmación antes de comprometerse con SVN. Esto está desactivado de forma predeterminada para los objetos.
que son confirmaciones y se fuerzan cuando se confirman objetos de árbol.

clave de configuración: svn.edit

-l , - encontrar-copias-más difíciles
Solo se usa con el comprometerse, conjunto-árbol y cometer-diferencia comandos.

Ambos se pasan directamente a git árbol de diferencias; ver git-diff-árbol(1) para más


clave de configuración: svn.l
clave de configuración: svn.findcopiesharder

-A , --authors-file =
La sintaxis es compatible con el archivo utilizado por git importacióncv:

loginname = Usuario Joe[email protected]>

Si se especifica esta opción y git svn encuentra un nombre de confirmador SVN que no
existen en el archivo de autores, git svn abortará la operación. El usuario tendrá que
agregue la entrada apropiada. Volver a ejecutar el anterior git svn comando después del
El archivo de autores se modifica debe continuar la operación.

clave de configuración: svn.authorsfile

--authors-prog =
Si se especifica esta opción, para cada nombre de confirmador SVN que no existe en el
Autores, el archivo dado se ejecuta con el nombre del confirmador como el primer
argumento. Se espera que el programa devuelva una sola línea con el formato "Nombre ",
que se tratará como si estuviera incluido en el archivo de los autores.

-q, - silencioso
Haz git svn menos detallado. Especifique una segunda vez para que sea aún menos detallado.

-m, - fusionar, -s , --strategy = , -p, --preserve-merges
Estos solo se utilizan con el comprometerse y rebase comandos.

Pasado directamente a git rebase cuando se utiliza comprometerse si un git reajustar no se puede utilizar (ver
comprometerse).

-n, --secar
Esto se puede utilizar con el comprometerse, rebase, biblioteca y etiqueta comandos.

Para comprometerse, imprima la serie de argumentos de Git que mostrarían qué diferencias
estar comprometido con SVN.

Para rebase, muestra la rama local asociada con el repositorio svn ascendente
asociado con la rama actual y la URL del repositorio svn que se obtendrá
desde.

Para biblioteca y etiqueta, muestra las URL que se utilizarán para copiar al crear el
rama o etiqueta.

--uso-registro-autor
Al recuperar svn se confirma en Git (como parte de ha podido recuperar, rebaseo comprometerse
operaciones), busque la primera línea De: o Firmado por: en el mensaje de registro y
utilícelo como la cadena de autor.

--add-autor-de
Al comprometerse con svn desde Git (como parte de cometer-diferencia, conjunto-árbol or comprometerse
operaciones), si el mensaje de registro existente no tiene un De: o
Firmado por: línea, agregue una línea De: basada en la cadena de autor de la confirmación de Git. Si
usa esto, luego --use-log-author recuperará una cadena de autor válida para todos
se compromete.

ADVANCED OPCIONES

-I , --identificación
Esto establece GIT_SVN_ID (en lugar de usar el entorno). Esto permite al usuario
anula el nombre de referencia predeterminado para obtenerlo cuando se realiza el seguimiento de una única URL. los log y
comprometerse Los comandos ya no requieren este modificador como argumento.

-R , --svn-remote
Especifique el [svn-remote " "] para usar, esto permite que SVN múltiples
repositorios que se deben rastrear. Predeterminado: "svn"

- seguir al padre
Esta opción solo es relevante si estamos rastreando ramas (usando uno de los repositorios
opciones de diseño --trunk, --tags, --branches, --stdlayout). Para cada rama rastreada, intente
para averiguar de dónde se copió su revisión y establecer un padre adecuado en el primer
Git commit para la rama. Esto es especialmente útil cuando estamos rastreando un directorio.
que se ha movido dentro del repositorio. Si esta función está desactivada, el
ramas creadas por git svn todos serán lineales y no compartirán ninguna historia, lo que significa que
no habrá información sobre dónde se ramificaron o fusionaron las sucursales. Sin embargo,
seguir historias largas / complicadas puede llevar mucho tiempo, por lo que deshabilitar esta función
puede acelerar el proceso de clonación. Esta función está habilitada de forma predeterminada, utilice
--no-follow-parent para deshabilitarlo.

clave de configuración: svn.followparent

CONFIG SOLO ARCHIVO OPCIONES

svn.noMetadata, svn-remote. .noMetadata
Esto elimina el git-svn-id: líneas al final de cada confirmación.

Esta opción solo se puede utilizar para importaciones únicas como git svn no podrá recuperar
de nuevo sin metadatos. Además, si pierde su $ GIT_DIR / svn / ** /. Rev_map. *
archivos, git svn no podrá reconstruirlos.

El git svn log El comando tampoco funcionará en repositorios que utilicen esto. Usando esto
conflictos con el usarSvmProps opción por (con suerte) razones obvias.

Esta opción NO se recomienda ya que dificulta la búsqueda de referencias antiguas.
a los números de revisión de SVN en la documentación existente, informes de errores y archivos. Si tu
planean migrar eventualmente de SVN a Git y están seguros de eliminar el historial de SVN,
que consideren rama-filtro-git(1) en su lugar. filter-branch también permite reformatear
metadatos para facilitar la lectura y reescribir la información de autoría para los que no son "svn.authorsFile"
usuarios.

svn.useSvmProps, svn-remote. .useSvmProps
Esto permite git svn para volver a mapear las URL del repositorio y los UUID de los espejos creados con
SVN :: Mirror (o svk) para metadatos.

Si una revisión SVN tiene una propiedad, "svm: headrev", es probable que la revisión haya sido
creado por SVN :: Mirror (también utilizado por SVK). La propiedad contiene un UUID de repositorio y
una revisión. Queremos que parezca que estamos reflejando la URL original, por lo que
introduzca una función auxiliar que devuelva la URL de identidad original y el UUID, y utilice
al generar metadatos en mensajes de confirmación.

svn.useSvnsyncProps, svn-remote. .useSvnsyncprops
Similar a la opción useSvmProps; esto es para usuarios del svnsync(1) comando
distribuido con SVN 1.4.xy posterior.

svn-remote. .rewriteRoot
Esto permite a los usuarios crear repositorios a partir de URL alternativas. Por ejemplo, un
el administrador podría ejecutar git svn en el servidor localmente (accediendo a través de file: //) pero deseo
para distribuir el repositorio con una URL http: // o svn: // pública en los metadatos para
los usuarios verán la URL pública.

svn-remote. .rewriteUUID
Similar a la opción useSvmProps; esto es para usuarios que necesitan reasignar el UUID
a mano. Esto puede resultar útil en situaciones en las que el UUID original no está disponible.
a través de useSvmProps o useSvnsyncProps.

svn-remote. .pushurl
Similar a Git's remoto. .pushurl, esta clave está diseñada para ser utilizada en casos donde
url apunta a un repositorio SVN a través de un transporte de solo lectura, para proporcionar una alternativa
transporte de lectura / escritura. Se supone que ambas claves apuntan al mismo repositorio.
Diferente a la confirmar, empujar es un camino base. Si alguno confirmar or empujar podría ser
usado, confirmar toma precedencia.

svn.brokenSymlinkSolución alternativa
Esto deshabilita las comprobaciones potencialmente costosas para solucionar los enlaces simbólicos rotos registrados en
SVN por clientes rotos. Establezca esta opción en "falso" si realiza un seguimiento de un repositorio SVN con
muchos blobs vacíos que no son enlaces simbólicos. Esta opción se puede cambiar mientras git svn is
en ejecución y surte efecto en la siguiente revisión obtenida. Si no está configurado, git svn asume esto
opción para ser "verdadero".

svn.codificación de nombre de ruta
Esto le indica a git svn que recodifique los nombres de ruta a una codificación determinada. Puede ser utilizado por
usuarios de Windows y por aquellos que trabajan en configuraciones regionales que no son utf8 para evitar nombres de archivos dañados
con caracteres no ASCII. Las codificaciones válidas son las que admite la codificación de Perl.
módulo.

svn-remote. .automkdirs
Normalmente, los comandos "git svn clone" y "git svn rebase" intentan recrear el vacío
directorios que están en el repositorio de Subversion. Si esta opción se establece en "falso",
entonces los directorios vacíos solo se crearán si se ejecuta el comando "git svn mkdirs"
explícitamente. Si no está configurado, git svn asume que esta opción es "verdadera".

Desde las opciones noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps y useSvmProps
todos afectan a los metadatos generados y utilizados por git svn; Se deben estar en el
archivo de configuración antes de importar cualquier historial y estas configuraciones nunca deben ser
cambiado una vez que se establecen.

Además, solo una de estas opciones se puede utilizar por sección svn-remote porque
afectar el git-svn-id: línea de metadatos, excepto rewriteRoot y rewriteUUID que pueden ser
usados ​​juntos.

ED. BÁSICA EJEMPLOS

Seguimiento y contribución al tronco de un proyecto administrado por Subversion (ignorando etiquetas y
sucursales):

# Clonar un repositorio (como git clone):
clon de git svn http://svn.example.com/project/trunk
# Ingrese al directorio recién clonado:
baúl de cd
# Debería estar en la rama maestra, verifique dos veces con 'git branch'
rama de git
# Trabaja un poco y comprométete localmente con Git:
git cometer...
# Algo está comprometido con SVN, reemplace sus cambios locales contra el
# últimos cambios en SVN:
git svn rebase
# Ahora confirme sus cambios (que fueron comprometidos previamente usando Git) a SVN,
# además de actualizar automáticamente su HEAD de trabajo:
git svn dcommit
# Append svn: ignora la configuración del archivo de exclusión predeterminado de Git:
git svn show-ignore >> .git / info / exclude

Seguimiento y contribución a todo un proyecto administrado por Subversion (completo con un tronco,
etiquetas y ramas):

# Clonar un repositorio con el diseño de directorio SVN estándar (como git clone):
clon de git svn http://svn.example.com/project --stdlayout --prefijo svn /
# O, si el repositorio usa un diseño de directorio no estándar:
clon de git svn http://svn.example.com/project -T tr -b rama -t etiqueta --prefijo svn /
# Ver todas las ramas y etiquetas que ha clonado:
git rama -r
# Crea una nueva sucursal en SVN
git svn rama waldo
# Restablezca su maestro a troncal (o cualquier otra rama, reemplazando 'troncal'
# con el nombre apropiado):
git reset --hard svn / trunk
# Solo puede dcommitir con una rama / etiqueta / troncal a la vez. El uso
El número de dcommit / rebase / show-ignore debe ser el mismo que el anterior.

La primera git svn clonar puede llevar bastante tiempo (especialmente para Subversion grandes
repositorios). Si varias personas (o una persona con varias máquinas) quieren utilizar git
svn para interactuar con el mismo repositorio de Subversion, puede hacer la git svn clonar
a un repositorio en un servidor y haga que cada persona clone ese repositorio con git clonar:

# Hacer la importación inicial en un servidor
servidor ssh "cd / pub && git svn clon http://svn.example.com/project [opciones ...] "
# Clonar localmente: asegúrese de que las referencias / controles remotos / espacio coincidan con el servidor
proyecto mkdir
proyecto de cd
git init
git remoto agregar servidor de origen: / pub / project
git config --replace-all remote.origin.fetch '+ refs / remotes / *: refs / remotes / *'
buscar
# Evite la recuperación / extracción del servidor Git remoto en el futuro,
# solo queremos usar git svn para futuras actualizaciones
git config --remove-section remoto.origen
# Crea una sucursal local a partir de una de las sucursales recién obtenidas
git pago -b maestro FETCH_HEAD
# Inicialice 'git svn' localmente (asegúrese de usar la misma URL y
# --stdlayout / -T / -b / -t / - opciones de prefijo como se usaron en el servidor)
iniciar git svn http://svn.example.com/project [opciones ...]
# Extraiga los últimos cambios de Subversion
git svn rebase

REBAJAR VS. TIRAR / FUSIONAR

Prefiero usar git svn rebase or git rebase, más bien que git recogida or git unir a
sincronizar confirmaciones no integradas con un git svn rama. Si lo hace, mantendrá el historial de
confirmaciones no integradas lineales con respecto al repositorio SVN ascendente y permiten el uso
de los preferidos git svn comprometerse subcomando para enviar confirmaciones no integradas de nuevo a SVN.

Originalmente, git svn recomendó que los desarrolladores se retiraran o se fusionaran de la git svn .
Esto se debió a que el autor favoreció a git svn set-tree B para asignar una sola cabeza en lugar de
la notación git svn set-tree A..B para realizar múltiples confirmaciones. Uso de git recogida or git
unir con git svn set-tree A..B hará que el historial no lineal se aplana cuando
comprometerse en SVN y esto puede llevar a fusionar confirmaciones revertir inesperadamente anteriores
confirma en SVN.

UNIR SEGUIMIENTO

Aunque la git svn puede rastrear el historial de copias (incluidas las ramas y etiquetas) para los repositorios
adoptando un diseño estándar, aún no puede representar el historial de fusión que sucedió dentro de git
backstream a los usuarios de SVN. Por lo tanto, se recomienda que los usuarios mantengan el historial tan lineal como
posible dentro de Git para facilitar la compatibilidad con SVN (consulte la sección AVISOS a continuación).

MANEJO OF SVN SUCURSALES

If git svn está configurado para buscar ramas (y --follow-branch está en efecto),
a veces crea múltiples ramas de Git para una rama SVN, donde las ramas adicionales
tener nombres de la forma branchname @ nnn (con nnn un número de revisión SVN). Estos adicionales
las ramas se crean si git svn no se puede encontrar una confirmación principal para la primera confirmación en un SVN
rama, para conectar la rama al historial de las otras ramas.

Normalmente, la primera confirmación en una rama SVN consiste en una operación de copia. git svn will
lea esta confirmación para obtener la revisión SVN desde la que se creó la rama. Entonces intentará
encuentre la confirmación de Git que corresponda a esta revisión SVN, y utilícela como padre de
la rama. Sin embargo, es posible que no exista un compromiso de Git adecuado para servir como
padre. Esto sucederá, entre otras razones, si la rama SVN es una copia de una revisión.
que no fue buscado por git svn (por ejemplo, porque es una revisión antigua que se omitió con
--revisión), o si en SVN se copió un directorio que no es rastreado por git svn (como una
rama que no se rastrea en absoluto, o un subdirectorio de una rama rastreada). En estos casos,
git svn seguirá creando una rama de Git, pero en lugar de utilizar una confirmación de Git existente como
padre de la rama, leerá el historial SVN del directorio en el que se copió la rama
desde y cree las confirmaciones de Git adecuadas. Esto se indica mediante el mensaje "Inicializando
padre: ".

Además, creará una rama especial llamada @, donde el
es el número de revisión SVN desde el que se copió la rama. Esta rama
apunte al compromiso padre recién creado de la rama. Si en SVN se eliminó la rama
y luego recreado a partir de una versión diferente, habrá múltiples ramas de este tipo con un
@.

Tenga en cuenta que esto puede significar que se crean múltiples confirmaciones de Git para una sola revisión SVN.

Un ejemplo: en un repositorio SVN con un diseño estándar de troncales / etiquetas / ramas, un directorio
trunk / sub se crea en r.100. En r.200, trunk / sub se ramifica copiándolo en branch /.
git svn clonar -s luego creará una rama por debajo. También creará nuevas confirmaciones de Git para
r.100 a r.199 y utilícelos como el historial de la rama por debajo. Así habrá dos Git
confirma para cada revisión de r.100 a r.199 (una que contiene trunk /, otra que contiene
tronco / sub /). Finalmente, creará una rama. sub @ 200 apuntando al nuevo compromiso padre de
biblioteca por debajo (es decir, el compromiso para r.200 y trunk / sub /).

AVISOS

En aras de la simplicidad y la interoperabilidad con Subversion, se recomienda que todos
git svn los usuarios clonan, obtienen y dcommit directamente desde el servidor SVN, y evitan todo git
clonar/ recogida /unir/empuje operaciones entre repositorios y sucursales de Git. El recomendado
El método de intercambio de código entre las ramas de Git y los usuarios es git parche de formato y git am,
o simplemente "comprometerse" con el repositorio de SVN.

Correr git unir or git recogida NO se recomienda en una sucursal que planea comprometerse obtenidos de
porque los usuarios de Subversion no pueden ver ninguna fusión que haya realizado. Además, si fusiona o
extraer de una rama de Git que es un espejo de una rama SVN, comprometerse puede cometer el error
.

Si fusiona, tenga en cuenta la siguiente regla: git svn comprometerse intentará comprometerse encima de
el compromiso SVN nombrado en

git log --grep = ^ git-svn-id: --first-parent -1

You deben por lo tanto, asegúrese de que la confirmación más reciente de la rama con la que desea comprometerse
son los first padre de la fusión. De lo contrario, se producirá el caos, especialmente si la primera
parent es una confirmación anterior en la misma rama SVN.

git clonar no clona ramas bajo las referencias / remotos / jerarquía o cualquier git svn
metadatos o config. Entonces, los repositorios creados y administrados con el uso git svn debe usar
rsync para la clonación, si es que se va a realizar la clonación.

Since comprometerse utiliza rebase internamente, cualquier rama de Git que git empuje a antes comprometerse on
requerirá forzar una sobrescritura de la referencia existente en el repositorio remoto. Este es
generalmente se considera una mala práctica, consulte el git-push(1) documentación para más detalles.

No utilice la opción --amend de compromiso de git(1) en un cambio que ya ha realizado. Eso
se considera una mala práctica - enmendar las confirmaciones que ya ha enviado a un repositorio remoto
para otros usuarios, y dcommit con SVN es análogo a eso.

Al clonar un repositorio SVN, si ninguna de las opciones para describir el repositorio
se utiliza el diseño (--trunk, --tags, --branches, --stdlayout), git svn clonar creará un Git
repositorio con historial completamente lineal, donde las ramas y las etiquetas aparecen como separadas
directorios en la copia de trabajo. Si bien esta es la forma más fácil de obtener una copia de un
repositorio, para proyectos con muchas ramas, dará lugar a una copia de trabajo muchas veces
más grande que solo el maletero. Por lo tanto, para proyectos que utilizan la estructura de directorios estándar
(tronco / ramas / etiquetas), se recomienda clonar con la opción --diseño estándar. Si el proyecto
utiliza una estructura no estándar y / o si no se requieren ramas y etiquetas, es más fácil
para clonar solo un directorio (normalmente el tronco), sin dar ningún diseño de repositorio
opciones. Si se requiere el historial completo con ramas y etiquetas, las opciones --maletero /
--sucursales / --etiquetas debe ser usado.

Cuando se utilizan múltiples --ramas o --etiquetas, git svn no maneja automáticamente el nombre
colisiones (por ejemplo, si dos ramas de diferentes rutas tienen el mismo nombre, o si un
rama y etiqueta tienen el mismo nombre). En estos casos, utilice init para configurar tu Git
repositorio entonces, antes de su primer ha podido recuperar, edite el archivo $ GIT_DIR / config para que el
las ramas y las etiquetas están asociadas con diferentes espacios de nombres. Por ejemplo:

ramas = estable / *: refs / remotes / svn / estable / *
ramas = debug / *: refs / remotes / svn / debug / *

Use git-svn en línea usando los servicios de onworks.net