Instrucciones de operación de SVN y estrategias de respaldo

2.1 Verificación de archivos

Después de instalar TortoiseSVN, SVN se integrará perfectamente con el Explorador de Windows. Haga clic con el botón derecho, podemos seleccionar la opción "SVN Checkout" en la barra de menú, ingresar la dirección URL de la biblioteca de archivos donde se va a extraer el código y podemos extraer los archivos en la biblioteca de archivos en la dirección URL. . De forma predeterminada, se desprotege la última versión del código. Si es necesario, podemos explorar los registros, encontrar la versión deseada según los registros y luego especificar la versión correspondiente en la opción "Versión" para verificar el código relevante.

Después, para el desarrollo principal del mismo proyecto, operaremos en este directorio de archivos de código extraído, en lugar de comprobarlo nuevamente para cada envío o actualización.

2.2 Adición de archivos

Los archivos (incluidos los directorios) que creamos localmente no serán controlados por SVN. Para aceptar el control de SVN, deben agregarse a la biblioteca de archivos. . Para los archivos que necesitan otros miembros del equipo, como archivos de código y archivos .a de ciertos módulos (debido a ciertas necesidades, el código del módulo no es público), debemos permitir que SVN los controle y mantener la última versión.

2.3 Eliminación de archivos

Cuando necesitamos eliminar archivos inútiles (incluidos directorios), no podemos usar las herramientas de administración de recursos de Windows, sino que debemos usar la función de eliminación de archivos del propio SVN. De esta manera, después de eliminar el archivo, todo su historial de modificaciones aún se guarda en el servidor SVN y aún se puede obtener el historial de modificaciones del archivo en el futuro.

2.4 Cambio de nombre de archivos

Cuando necesitamos cambiar el nombre de archivos (incluidos directorios), no podemos usar las herramientas de administración de recursos de Windows, sino que debemos usar la función de cambio de nombre de archivos del propio SVN. De esta manera, después de cambiar el nombre del archivo, todo el historial de modificaciones antes del cambio de nombre aún se guarda en el servidor SVN, manteniendo la información de modificación continua.

2.5 Actualización de archivos

Los cambios enviados a SVN por otros miembros del equipo no se actualizarán automáticamente en su copia local. Necesitamos actualizar el archivo para obtener los comentarios de otros miembros sobre el proyecto. Modificaciones realizadas al fichero. La operación de actualización del archivo SVN fusionará los archivos de la biblioteca de archivos con los archivos locales, logrando así el propósito de conservar las modificaciones de otros miembros y las modificaciones locales al mismo tiempo. Si no es posible la combinación automática, se producirán conflictos y deberá utilizar una herramienta de comparación de archivos para la combinación manual. Sólo después de que se complete la combinación se podrán enviar los archivos resueltos en conflicto. Para conocer métodos detallados de resolución de conflictos, consulte el Capítulo 3: Resolución de conflictos.

En el desarrollo del equipo, la actualización es una tarea muy importante para mantener consistente el contenido del trabajo entre los miembros del equipo. Por lo tanto, debe prestar atención a actualizar su copia de trabajo con frecuencia para asegurarse de poder obtener las últimas modificaciones. .

2.6 Envío de cambios

Todos los cambios que realizamos en los archivos (incluidos los directorios), incluida la adición, eliminación y modificación de archivos, deben enviarse a la biblioteca de archivos del servidor SVN para que entren en vigor oficialmente. Sólo entonces otros miembros del equipo podrán acceder a sus cambios.

El envío es una operación muy importante y requiere lo siguiente: Antes de enviar el código, debe asegurarse de que el código modificado se pueda compilar y pasar. No puede enviar código que no pase la compilación. Compare el código antes y después de la modificación, elimine la información de depuración u otra información irrelevante y asegúrese nuevamente de que el código enviado sea correcto y que los archivos que deben enviarse estén enviados. No espere hasta haber modificado una gran cantidad de código antes de enviarlo, envíelo una vez cuando se completen las pequeñas funciones relevantes. Esto facilita deshacer el código problemático cuando se descubren problemas más adelante; debido a que deshacer solo se puede aplicar a un envío, no se recomienda involucrar demasiadas funciones en un solo envío. Al enviar, debe completar la información de registro para explicar qué funciones se agregaron o errores corregidos en este envío. Esta información le ayuda a usted y a otros miembros del equipo a comprender la historia de todo el proyecto. También es conveniente localizar el código de versión correspondiente cuando ocurre un problema, por lo que la información del registro debe ser lo suficientemente detallada. Compromiso transaccional.

Es decir, el envío se realiza correctamente o fracasa por completo; es decir, cuando se produce un error en el envío, se revierte automáticamente y en realidad no se envía nada. Cuando se produzca un error, resuélvalo y vuelva a enviar todo el contenido enviado la última vez.

3. Resolución de conflictos

La resolución de conflictos es un tema espinoso en nuestro uso de SVN, por lo que se discutirá en una sección separada.

3.1 Ocurrencia de conflictos

Los conflictos ocurren cuando varios miembros modifican el mismo archivo al mismo tiempo. Es decir, cuando otros miembros han enviado modificaciones y también han modificado el archivo en la copia local, y las modificaciones están en el mismo lugar, al actualizar el archivo local, SVN no sabrá qué modificación elegir (Modificaciones en SVN o modificaciones locales) se fusionan, por lo que surgen conflictos.

Por ejemplo, si el contenido actual del archivo Day.txt controlado por SVN en el servidor SVN es el siguiente:

Gráfico 3 Modificaciones locales del archivo Day.txt

Podemos ver que la primera línea de texto ha sido modificada tanto en SVN como localmente. De esta manera, cuando se actualiza localmente (debe actualizarse antes de enviar), SVN no sabe si el lunes debería funcionar o dormir después de la fusión, por lo que surgen conflictos.

Las filas tercera y quinta se modificaron por separado y no hay conflicto, por lo que estas dos filas se pueden fusionar sin problemas. Después de la fusión, puede ver las modificaciones realizadas por todos.

3.2 Resolución de conflictos

Después de que ocurre un conflicto, SVN guardará diferentes versiones modificadas del archivo localmente, como se muestra en el ícono azul a continuación:

Gráfico 4 Diferentes versiones del archivo Day.txt Day.txt.r35 es el archivo Day.txt de la versión 35 (la última versión copiada localmente) Day.txt.r37 es el archivo Day.txt de la versión 37 (la última versión en SVN) Day.txt.mine es el archivo Day.txt modificado localmente. El archivo Day.txt contiene el contenido fusionado

3.2.1 Resolución de conflictos simple

Para conflictos de contenido simples, podemos. Modifique directamente el archivo fusionado. En el ejemplo anterior, abrimos el archivo Day.txt y podemos ver el contenido combinado de SVN:

Gráfico 5: El contenido combinado de Day.txt

No vemos modificaciones conflictivas (jugar baloncesto) y (reunión) se fusionaron con éxito y aparecieron algunas marcas en las partes en conflicto. donde las etiquetas

lt;lt;lt;lt;lt;lt;lt; .mine

========

es el contenido de la parte conflictiva modificado localmente, es decir, el lunes (trabajo). Y las etiquetas

=======

gt;gt;gt;gt;gt;gt;gt .r37

Es el contenido de la versión 37 (la última versión en SVN), es decir, lunes (dormir).

Sin pérdida de generalidad, si el contenido que queremos conservar ahora es el lunes (trabajo), entonces solo necesitamos eliminar la parte de marca y lunes (dormir):

Gráfico 6 Contenido de Day.txt después de la resolución del conflicto

Después de asegurarse de que las modificaciones sean correctas, configure el archivo Day.txt en "Resuelto".

Gráfico 7 Day.txt se marca como resuelto

Después de eso, los archivos con el sufijo mine, r35 y r37 desaparecen, y solo queda el archivo Day.txt con los conflictos resueltos. y se envía a SVN. Eso es todo.

3.2.2 Resolución de conflictos complejos

Para archivos con contenidos complejos, la solución anterior puede omitir fácilmente algunas partes que deben modificarse, y la solución también requiere mucho tiempo y intensivo en mano de obra. Esto debe resolverse mediante las herramientas proporcionadas por SVN.

Seleccione la función SVN "Editar conflicto" para abrir la herramienta de edición de conflictos:

Herramienta de edición de conflictos del Gráfico 8

Las dos columnas de contenido en la parte superior son Se muestra por separado Es el contenido de la versión 37 y el contenido de las modificaciones locales.

La columna de contenido en la mitad inferior muestra el contenido combinado.

La marca a la izquierda de cada columna de contenido identifica claramente los cambios que se han realizado en el archivo.

Las partes conflictivas de los archivos están resaltadas en rojo. En la barra de combinación, haga clic en la parte en conflicto y haga clic derecho. Podemos elegir qué contenido (el contenido más reciente en SVN o el contenido modificado localmente) usar para resolver la parte en conflicto. También podemos elegir usar ambos contenidos y seleccionar. el orden en que aparecen.

Resuelve cada conflicto uno a uno. Después de asegurarse de que se hayan resuelto todos los conflictos, guarde el archivo, márquelo como "resuelto" y salga de la herramienta para completar la resolución del conflicto.

4. Estrategia de bloqueo

De hecho, hay otra forma de resolver conflictos, y es el "bloqueo estricto".

El "bloqueo estricto" requiere que el archivo esté bloqueado antes de editarlo. En este momento, otros miembros del equipo no pueden editar el archivo, lo que garantiza que solo una persona esté editando el archivo al mismo tiempo, evitando así conflictos.

Entonces, ¿qué tipo de archivos deberíamos adoptar un "bloqueo estricto"? Debemos "bloquear estrictamente" archivos como Excel e imágenes que no se pueden fusionar. Los archivos "estrictamente bloqueados" se marcan como "legibles", es decir, no se pueden editar. Para editar estos archivos "estrictamente bloqueados", primero debe bloquearlos. Después de bloquearlos, los archivos se cambiarán a "legibles y escribibles". Este tipo de documento debe enviarse lo antes posible después de su edición. Cuando se complete la confirmación, SVN desbloqueará automáticamente cualquier bloqueo que tenga. Para archivos de texto, como el código de programa, SVN generalmente puede fusionar cambios sin un "bloqueo estricto". Para algunos archivos de código fuente importantes que todos cambian con frecuencia, pueden causar muchos conflictos. No recomendamos el "bloqueo estricto" porque el bloqueo hará que todos sigan preguntando sobre el estado del bloqueo. El enfoque correcto es dividir el archivo en varias unidades lógicas y cada uno puede modificar sus propias unidades para reducir los conflictos durante la fusión.

5. Etiqueta amp; rama

El directorio donde se almacena inicialmente un proyecto se llama troncal. A continuación analizamos otros directorios para almacenar proyectos además del tronco: etiquetas y ramas.

Etiqueta 5.1

El número de versión puede distinguir múltiples modificaciones de código. Podemos usar el número de versión para verificar el código requerido, pero para versiones importantes del código, como la tercera. versión del código de lanzamiento, no queremos recordar números como r37. En este momento, podemos crear una etiqueta para crear una "instantánea" del estado de la versión de lanzamiento del archivo en SVN en este momento. Más tarde, podemos usar este nombre de etiqueta para verificar el código de la tercera versión de lanzamiento.

Una etiqueta es en realidad una copia simple del archivo del proyecto actual, guardada en el directorio donde se encuentra la etiqueta. Crear etiquetas también es bastante simple, pero tenga en cuenta: el nombre de la etiqueta debe ser descriptivo, para que pueda saber por qué se crea la etiqueta solo por el nombre. No uses demasiadas etiquetas. Crea etiquetas solo para momentos o lanzamientos importantes. Las etiquetas son el estado del archivo del proyecto en un momento determinado y no se pueden modificar.

5.2 Rama (rama)

Una rama, como una etiqueta, es una copia simple del archivo del proyecto actual y se guarda en el directorio donde se encuentra la rama.

La diferencia fundamental entre ramas y etiquetas es que las etiquetas no se pueden modificar, mientras que las ramas se crean para modificaciones con un propósito determinado. Simplemente consulte la rama especificada al verificar el código. Las operaciones en la rama son exactamente las mismas que en la troncal.

5.2.1 Cuándo crear

Al encontrarnos con las siguientes situaciones, podemos solucionar el problema creando una rama: Liberar rama

Cuando estamos a punto de lanzar una versión Ahora, un pequeño equipo de desarrollo necesita prepararse para este lanzamiento, como corregir algunos errores finales. Lo que necesitan en este momento es la estabilidad del proyecto y, al mismo tiempo, tenemos otros equipos desarrollando funciones que no se espera que se agreguen hasta la próxima versión. Obviamente no pueden trabajar en el mismo código, por lo que necesitamos compilar. uno nuevo de la rama de lanzamiento principal, el equipo de lanzamiento verifica y envía el código desde esta rama de lanzamiento. Una vez publicado el programa, esta rama permanece activa. De esta manera, si los clientes informan algunos errores, el equipo los corregirá en esta rama de versión y los fusionará en el tronco según corresponda. Rama experimental

Se puede establecer un experimento cuando necesitamos realizar cambios a gran escala en el proyecto, y este cambio tendrá un impacto profundo en el resto del sistema, y ​​no podemos garantizar que este cambio lo haga. tener éxito en la sucursal. Si el experimento falla, la rama se puede abandonar; si tiene éxito, solo necesitamos fusionar los cambios de la rama en el código principal.

En otros casos, no recomendamos crear ramas, y mucho menos crear ramas sobre ramas, porque con demasiadas ramas, los conflictos durante la fusión serán un desastre difícil de resolver.

5.2.2 Fusionar ramas

Es probable que los errores que solucionamos en la rama también existan en el tronco u otras ramas, porque a menudo provienen del mismo código, por lo que cambiamos realizado en la rama debe fusionarse con el tronco u otras ramas.

Para errores simples, un envío puede resolver el problema. Luego solo debemos recordar enviar un nuevo número de versión y luego usar el nuevo número de versión para fusionar los cambios en otras troncales y ramas afectadas.

Para errores complejos, es posible que varios desarrolladores dediquen varios días y los envíen varias veces para solucionarlos. En este momento, es un poco difícil utilizar el número de versión para recordar el contenido modificado. Por lo tanto, podemos usar etiquetas para marcar el comienzo y el final de nuestro proceso de corrección, y luego usar estas etiquetas para ayudarnos a fusionar el código corregido en el tronco y otras ramas. Todo el proceso es el siguiente:

① Etiqueta la rama y marca la modificación del error para comenzar.

② Prueba para reproducir el error y corregir el código para que la nueva prueba pase.

③ Envíe sus cambios a SVN.

④ Repite los pasos 2 y 3 hasta que estés seguro de que el error ha sido corregido.

⑤ Agregue una etiqueta a la rama para marcar el final de la corrección del error.

⑥ Utilice dos etiquetas para fusionar el código corregido con todos los demás troncos y ramas afectados.

6. Notas

Actualice con frecuencia Dado que los archivos pueden ser modificados por varias personas, los archivos en su copia de trabajo deben actualizarse con frecuencia para reducir la posibilidad de conflictos.

Pruebe el envío Pruebe localmente antes de enviar. No se permite enviar archivos con errores al servidor SVN.

Complete los comentarios Asegúrese de escribir comentarios al enviarlos: los comentarios ayudarán a otros (incluido usted mismo tres meses después) a comprender los cambios que realizó en el archivo.

Envío general Al enviar archivos, asegúrese de enviar todos los archivos correspondientes a un cambio. No envíe un archivo a la vez o un montón de archivos que modifiquen muchas funciones a la vez.

Etiquetas de lanzamiento Cree etiquetas para cada versión lanzada: cuando un usuario le informa que ocurre un problema, puede rastrear rápidamente en qué versión se introdujo el problema.

Adjunto: Directrices para el uso de SVN por parte del equipo de automatización de pruebas

1 Construcción del proyecto

La estructura de directorios del proyecto en el servidor SVN es la siguiente. siguiente:

Archivos de proyecto en SVN:

1. ¡El código en el Trunk debe estar actualizado! Actualice periódicamente el código en Trunk y cada equipo pueda controlarlo de acuerdo con su situación real.

2 La etiqueta es una etiqueta basada en las necesidades del proyecto. Cada versión lanzada debe etiquetarse, principalmente por conveniencia. Cuando sea necesario, puede volver directamente al estado anterior según la etiqueta para facilitar el análisis y las pruebas. La etiqueta debe contener el archivo de lanzamiento correspondiente y el código fuente cuando se compila o publica en ese momento, y debe haber documentos relevantes que indiquen el proyecto; antecedentes, estado de publicación, etc.

3. La carpeta Branch se puede usar para realizar copias de seguridad y la carpeta se puede nombrar con un nombre personal. Además, la sucursal Branch se usa principalmente para desarrollo exploratorio o a corto plazo y el software final; La versión debe actualizarse y fusionarse. Vaya al tronco.

4. Sugerencias sobre el entorno de desarrollo del mismo equipo de proyecto: los entornos de desarrollo de los miembros del mismo equipo de proyecto deben ser consistentes, y la ruta de instalación del software y la ruta de almacenamiento de archivos del proyecto deben ser consistentes.

2. Número de versión

Acerca de las reglas de nomenclatura del número de versión: número de versión principal. número de versión revisada

1. primera versión, versión El número es 0.1.0;

2. Cuando el proyecto sufre una modificación parcial o corrección de errores, tanto el número de versión principal como el número de subversión permanecen sin cambios, y el número de versión revisada es. aumentado en 1;

3. Cuando se agregan algunas funciones al proyecto sobre la base original, el número de versión principal permanece sin cambios, el número de subversión aumenta en 1 y el número de versión revisada se restablece a 0;

4. Cuando el proyecto sufre modificaciones importantes o cuando hay demasiadas correcciones locales acumuladas, lo que resulta en cambios globales en todo el proyecto, el número de versión principal se incrementa en 1 y el número de versión secundaria. el número de versión y el número de versión revisada se restablecen a 0;

5. El número de versión compilada generalmente lo determina el compilador. Solo definimos su formato. generelo automáticamente, agréguelo manualmente y el valor representa la hora actual del sistema.

Ejemplo: V1.0.1 Build090305 Rel111123

Reglas para usar otras versiones:

1. Versión beta interna Alpha (alphal)

Esta versión indica que el software es solo un producto preliminar completado y solo se comunica dentro del grupo. Esta versión del software tiene muchos errores y está limitada a pruebas internas.

Ejemplo: V0.1.1 Build090305 alphal1

Versión de prueba externa Beta (beta)

Esta versión ha sido muy mejorada en comparación con la versión alfa. Al realizar pruebas dentro del grupo, se han eliminado errores graves, pero aún quedan algunos defectos que deben eliminarse mediante pruebas a gran escala.

Ejemplo: V0.1.2 Build090305 beta1

Versión demo demo 3.

Solo se puede utilizar como introducción durante la revisión o explicación.

Ejemplo: V0.1.3 Build090305 demo1

4. Versión final de lanzamiento

Esta versión significa "versión de lanzamiento final" y ha lanzado una serie de versiones de prueba después. Eso, eventualmente habrá una versión oficial. En circunstancias normales, el lanzamiento no aparecerá como una palabra en la portada del software, sino que será reemplazado por un símbolo (Rel). Cuando se lanza una versión de lanzamiento, el software que se lanzará y los registros de actualización de la versión correspondiente deben empaquetarse y publicarse juntos.

Ejemplo: V1.0.1 Build090305 Rel111123

3. Restricciones de permisos

Si el proyecto en sí necesita controlar diferentes permisos para los miembros del equipo del proyecto, puede considerar mantenerlos. dos proyectos: un proyecto tiene los archivos fuente correspondientes y el otro solo tiene los archivos compilados.

4. Mantenimiento de la versión del módulo

1. Los archivos generalmente no requieren versiones, pero deben tener registros detallados del historial de actualizaciones;

2. versiones Para mantener, se puede distinguir por diferentes carpetas.