visual studio - studio - Uso básico de SVN

visual studio code gitlab (10)

Prefacio

Permítanme comenzar diciendo que soy un programador relativamente nuevo y no tengo experiencia previa con el control de código fuente, aunque después de algunas lecturas, los conceptos y la jerga general no me son ajenos.

Fondo

Estoy a punto de comenzar mi primer proyecto profesional (seré el único que se comprometa) y me gustaría aprovechar esta oportunidad para dominar la práctica de Subversión y control de fuentes en general.

El desarrollo se llevará a cabo en un cuadro de Windows en Visual Studio con la ayuda del complemento AnkhSVN SC.
He configurado SVN en un servidor de Windows y he creado un repositorio donde almacenaré mi (s) proyecto (s).
Este proyecto en particular requerirá la entrega de binarios y código fuente.

Preguntas

¿Cómo se configura la creación de soluciones generalmente? Digamos que he importado una versión inicial de la solución en el repositorio; A continuación, he logrado un hito en mi copia de trabajo local; Me comprometo con esos cambios; ¿Qué pasa entonces? ¿Acabo de crear la solución en mi máquina de desarrollo local y empaquetar los binarios allí mismo? ¿Cómo se hace esto en el mundo real?
Después de jugar con VS y AnkhSVN en una máquina virtual, me he dado cuenta de que después de revisar una revisión de una solución, el árbol de directorios de mi copia local obtiene un directorio adicional llamado ".svn" en cada nodo. Según el tercer punto en "Fondo", también entregaré el código fuente junto con los binarios. Esto plantea una pregunta: ¿cómo obtengo una versión "limpia" de mi solución? ¿Espero escribir un script de shell que haga la limpieza por mí?
A menudo creo, fusiono (a mano, eso es) y borro archivos en mis soluciones. ¿SVN (en lugar de VS y AnkhSVN) manejará esto con gracia? ¿VS / AnkhSVN volverá a cargar automáticamente una solución a la que se agregaron / eliminaron archivos si vuelvo a una cierta revisión?
¿Dónde aprendió a usar el control de código fuente y cuánto tiempo tardó en convertirse en competente (es decir, hasta que estas operaciones fueran una segunda naturaleza)?

Tengo muchas ganas de comenzar a usar el control de código fuente, pero tengo miedo de que si comienzo a usarlo y hago algo sin querer, perderé mi código. Cualquier consejo adicional es apreciado.

¿Cómo se configura la creación de soluciones generalmente? Digamos que he importado una versión inicial de la solución en el repositorio; A continuación, he logrado un hito en mi copia de trabajo local; Me comprometo con esos cambios; ¿Qué pasa entonces? ¿Acabo de crear la solución en mi máquina de desarrollo local y empaquetar los binarios allí mismo? ¿Cómo se hace esto en el mundo real?

La mayoría de los lugares se han estandarizado en un proceso de construcción automatizado. La forma de configurar uno varía según los requisitos de la empresa y el proyecto, pero los beneficios no se pueden disputar. El último lugar donde trabajé automatizó el 90% de la construcción y lo ejecuté según lo necesario, pero cuando me fui se estaban moviendo hacia uno completamente automático. Esto está fuera del alcance de su pregunta, pero si está interesado, debe buscar la automatización de la construcción. Algunas herramientas comunes para el desarrollo de .NET son CruiseControl.NET, MSBuild, NANT. La mayoría de las herramientas se crearon para un entorno de desarrollo o idioma específico, pero se adaptan fácilmente a otros entornos.

Después de jugar con VS y AnkhSVN en una máquina virtual, me he dado cuenta de que después de revisar una revisión de una solución, el árbol de directorios de mi copia local obtiene un directorio adicional llamado ".svn" en cada nodo. Según el tercer punto en "Fondo", también entregaré el código fuente junto con los binarios. Esto plantea una pregunta: ¿cómo obtengo una versión "limpia" de mi solución? ¿Espero escribir un script de shell que haga la limpieza por mí?

Como han señalado otros, .svn es un caché del repositorio. Cuando actualiza, registra o combina, svn compara la versión almacenada en caché con la operación que pretende hacer y solo actualiza, registra, fusiona las diferencias. En el caso de AnkhSVN, se integra bastante bien con VS y está diseñado para ignorar archivos innecesarios cuando registra archivos. Por lo tanto, no debería tener problemas con el registro de archivos temporales y archivos binarios (a menos que los agregue específicamente, por supuesto).

A menudo creo, fusiono (a mano, eso es) y borro archivos en mis soluciones. ¿SVN (en lugar de VS y AnkhSVN) manejará esto con gracia? ¿VS / AnkhSVN volverá a cargar automáticamente una solución a la que se agregaron / eliminaron archivos si vuelvo a una cierta revisión?

Este es el fuerte de SVN. Algunos VCS (como Visual Source Safe) hacen que la fusión sea una operación aterradora. Por otra parte, SVN fue diseñado específicamente con operaciones de fusión en mente. La mayoría se manejan automáticamente. Si hay un conflicto entre las versiones que se fusionan (la misma línea se modificó de dos maneras diferentes), le mostrará el problema y el resto depende de usted. Es muy difícil eliminar realmente un archivo en SVN. Por lo tanto, si decide explorar una versión anterior, cualquier archivo eliminado seguirá siendo el suyo.

¿Dónde aprendió a usar el control de código fuente y cuánto tiempo tardó en convertirse en competente (es decir, hasta que estas operaciones fueran una segunda naturaleza)?

Había oído hablar de VCS en la universidad, pero nunca usé uno hasta mi primera posición de programación paga. Era una fuente visual segura. Fue bastante fácil aprender lo básico (revisar, registrar, comentar, ver y comparar versiones antiguas). Ramificación que aprendí más tarde con un repositorio privado. Fue algo bueno también. La ramificación en VSS es más propensa a errores que la mayoría de los otros VCS. Mi empleador actual usa SVN, que aunque no es el VCS más avanzado disponible, hace que VSS parezca un hack.

No puedo enfatizar la importancia de una compilación automatizada lo suficiente. Mi empleador actual no tenía ningún proceso de compilación cuando comencé (aún no lo hace para la mayoría de los proyectos). Una de las primeras cosas que hice con el proyecto que heredé fue automatizar todo el proceso de construcción. Se ejecuta en un servidor dedicado como un proceso en segundo plano que supervisa los cambios de SVN. Si detecta alguno, inicia una construcción incremental que solo toma unos segundos. A esto le sigue un conjunto de pruebas unitarias automatizadas. Si todas las pruebas tienen éxito, los binarios caen en un entorno de prueba para una mayor integración automatizada y pruebas del sistema. Me avisan en cada paso del proceso y sé instantáneamente si algo falla.

Después de cometer tus cambios personales, construirías localmente. Por lo general, construirías localmente y probarías antes de cometer. En el mundo real, todos los desarrolladores trabajan en el mismo SVN y generalmente hay una compilación nocturna donde puede obtener binarios actualizados y, por supuesto, reconstruirlos según sea necesario a nivel local. En su caso, simplemente reconstrúyalo según lo dicte el caso, envíe su código fuente de manera compulsiva y luego realice los binarios todos los días.
Esto parece un problema de configuración de SVN y Visual Studio. Consultaría esos foros por ayuda.
Por lo general, manejará la solución en su extremo, es decir, cuando agregue y elimine archivos, su solución local cambiará y, como las soluciones son pequeñas, también cargará esta solución a su SVN. Cualquier SVN puede manejar la adición y eliminación de archivos.
Comencé con el código y subclipse de Google, graduándome a Tortoise SVN. Tortoise SVN es agradable porque se integra en el shell, por lo que puede desarrollar en cualquier IDE que desee y tratar sus archivos locales como archivos locales, y simplemente confirmarlos cuando sea necesario.

Solo es extraño al principio, pero un SVN se convertirá rápidamente en una segunda naturaleza para ti. Buena suerte en tu proyecto.

Normalmente, los binarios empaquetados no se mantienen en el control de origen. En todo caso, utilice un repositorio separado para ellos. De hecho, trate de mantener los binarios alejados de su repositorio si es posible. No hay versiones compiladas de su código fuente. ( ver comentarios también )
Obtenga TortoiseSVN para usar en Explorer. Puede usar la opción Exportar (en lugar de pagar) para una versión limpia del directorio. Utilice un directorio separado para esto.
Visual Studio le preguntará si desea volver a cargar proyectos o soluciones que han cambiado. Sin embargo, deberá asegurarse de registrar un proyecto al mismo tiempo que su archivo agregado / eliminado. No le dará problemas ahora, pero lo haría si estuviera trabajando en esto con más de una persona o si desea volver a una versión anterior más tarde.
Aquí y allá :) Me tomó aproximadamente un mes de uso regular para hacerlo bien *

He usado AnkhSVN en el pasado y es bueno, pero si tiene soluciones grandes con muchos archivos, es posible que desee desembolsar algo de dinero para VisualSVN . Utiliza TortoiseSVN (que a su vez tiene algunos mecanismos de almacenamiento en caché), ~~lo que lo hace más rápido~~ ( vea el comentario más abajo sobre AnkhSVN 2.0 ). VisualSVN también le ayudará un poco en la configuración de propiedades en directorios especiales. Ignorará automáticamente los directorios bin y obj , por ejemplo.
No soy un gran fanático de pagar por un producto que se apoya tanto en un proyecto gratuito, pero debo decir que la inversión valió la pena.

Otras personas han vinculado algunas fuentes interesantes sobre cómo configurar tu repositorio, por lo que no voy a entrar en eso demasiado. Generalmente uso el /trunk , /branches , /tags me acerco. Etiqueta tus versiones de lanzamiento al menos, para encontrarlas rápidamente más tarde.

Anuncio 4:
He trabajado con CVS (muy poco), Visual SourceSafe, Subversion y Team Foundation Server hasta ahora. Quiero probar Git en algún momento, pero podrías hacerlo mucho peor que SVN.

La forma en que almaceno mis archivos en Subversion es configurar los directorios Trunk / Branch / Tag, aunque casi nunca uso etiquetas. Tu baúl es tu base sólida de trabajo. Las ramas son cuando necesitas "ramificar" el código, trabajar en algo y luego fusionarlo de nuevo en el tronco. Puedes hacer esto por algo que sabes que tomará un tiempo y sabes que quizás debas hacer algunos arreglos rápidos, que modifican el tronco. ¿Tener sentido?
- Puedes sacar tu última versión y hacer una compilación localmente o configurar un entorno de compilación utilizando MSBuild, Cruise Control.NET o TeamCity (de los que hacen resharper). Esto hará una compilación para ti, que luego podrás implementar. Todo esto puede ser automatizado, es solo un trabajo de configuración de todo. Team Foundation Server maneja la mayor parte de esto.
El directorio .svn es para que Subversion sepa en qué estás trabajando y pueda decir "hey algo cambió, alertar al usuario con una buena marca roja y avisarle que algo ha cambiado".
Sí, SVN se encargará de eliminar y fusionar con gracia. Es posible que se vea obligado a utilizar la utilidad de "limpieza" de vez en cuando.
Aprendí el control de código fuente de un desarrollador senior en mi primer proyecto.

4) Empiezo con éste porque responderá muchas de sus primeras preguntas: el Control de Versión Pragmático usando Subversion es la biblia para trabajar con SVN en mi aspecto. Pero a diferencia de la Biblia, puedes leerla en un par de días sin ninguna prisa.

1) Los proyectos de versiones generalmente toman la forma de confirmar solo los archivos de origen, ya que los archivos de proyecto (de su VS, por ejemplo) generalmente contienen definiciones irrelevantes de su instalación actual, y ensucian el repositorio. Los compromisos diarios son para su uso personal. Para las versiones principales use etiquetas.

2) El directorio .svn es un repositorio de caché local completamente administrado por el cliente SVN. No lo toques

3) De lo que se trata el control de versiones es fusionar, eliminar y agregar archivos. Sí, SVN manejará esto con gracia, y todo esto se explica fácilmente en el libro al que se hace referencia. Cada revisión de su proyecto es autónoma.

Deberías leer el book . Es gratis y tiene respuestas a preguntas como la pregunta 2 (Respuesta: exportar).

No puedo responder a tus preguntas principales porque son muy específicas de VS, pero cuando dices:

Tengo miedo de que si comienzo a usarlo y hago algo estúpido involuntariamente, perdería mi código.

Déjame tranquilizarte. El objetivo principal de un VCS es evitar cualquier pérdida de código, nunca. Soy consciente de que todos los sistemas de control de versiones hacen imposible modificar versiones anteriores de sus archivos sin saltar a través de algunos problemas extremadamente improbables, como editar directamente el repositorio con un editor de texto o hexadecimal. Mientras no haga eso, y siempre que haga una copia de seguridad de su repositorio con regularidad, su código estará seguro y usted debería sentirse libre para experimentar.

Personalmente tomé el control de la fuente a través de prueba y error. Creo que Sourcegear Vault es mucho más fácil de usar y está mejor adaptado para el desarrollo de Visual Studio, pero he logrado usar ambos de manera efectiva.

Si tiene problemas con SVN, le recomiendo que revise la bóveda, que es gratuita para uno o dos equipos. (Un administrador y una cuenta de usuario no requieren una compra.)

Voy a intentar agregar algunos comentarios que no hayan sido cubiertos por las respuestas bien escritas arriba.

¿Cómo se configura la creación de soluciones generalmente? Digamos que he importado una versión inicial de la solución en el repositorio; A continuación, he logrado un hito en mi copia de trabajo local; Me comprometo con esos cambios; ¿Qué pasa entonces? ¿Acabo de crear la solución en mi máquina de desarrollo local y empaquetar los binarios allí mismo? ¿Cómo se hace esto en el mundo real?

Se debe tener en cuenta que ignorar ciertos archivos es una función central de SVN, por lo que no se necesitan herramientas adicionales, solo algunas configuraciones. Una vez que haya configurado SVN para ignorar el resultado de su compilación, puede desarrollarlo y compilarlo a su gusto sin preocuparse de que SVN intente absorber los binarios.

Etiqueta tus lanzamientos. Utilice el número de versión en el lanzamiento en el nombre de la etiqueta. Construya sus binarios a partir de la etiqueta y envíe a su cliente una copia limpia de la fuente, así como los binarios generados. No necesita revisar los binarios en sí mismos porque la inmutabilidad de las etiquetas significa que siempre podrá volver a generar la misma carga útil.

A menudo creo, fusiono (a mano, eso es) y borro archivos en mis soluciones. ¿SVN (en lugar de VS y AnkhSVN) manejará esto con gracia? ¿VS / AnkhSVN volverá a cargar automáticamente una solución a la que se agregaron / eliminaron archivos si vuelvo a una cierta revisión?

Hay algunas operaciones con las que VCS suele tener problemas. Una es eliminar un archivo revisado usando el Explorador de Windows (también conocido como: eliminar teclado). Otro es mover los archivos revisados de un lugar en su repositorio a otro desde el Explorador de Windows. Fuera de estas acciones semi-raras, SVN se mantendrá al día con sus modificaciones y combinaciones. Para los dos eventos mencionados anteriormente, puede usar la línea de comandos SVN, TortoiseSVN u otra aplicación de ayuda para realizar un ''Eliminar SVN'' o ''Eliminar SVN + SVN (re) agregar''.

Por cierto, una herramienta de combinación buena (y gratuita) es Kdiff3 .

¿Dónde aprendió a usar el control de código fuente y cuánto tiempo tardó en convertirse en competente (es decir, hasta que estas operaciones fueran una segunda naturaleza)?

Aprendí SVN en el trabajo, Mercurial en casa y AccuRev en el trabajo (otra vez). Puede llevar mucho tiempo ''obtener'' su primer VCS, especialmente si lo está aprendiendo en el vacío. Después de la primera, se vuelve más fácil. Yo pondría esto en el orden de meses, no semanas.

¡Buena suerte!

Voy a secundar la recomendación de Avihu Turzion de Pragmatic Version Control usando Subversion. También puedes ver el manual de control de Eric Sink si aún no lo has hecho.

Ya que usted es el único que confía, construir y empaquetar los binarios localmente es definitivamente una opción. Si los pasos de construcción / empaque son bastante estándar, automatícelos configurando un sistema de integración continua. TeamCity Professional es un producto gratuito con el que puede comenzar, que es fácil de configurar y trabajar con Subversion.
Como lo mencionaron otros, la opción Exportar es la forma de obtener una versión de su solución sin los archivos .svn.
Subversion maneja la creación, la fusión y la eliminación de archivos de manera bastante fluida. Con los complementos que menciona, especialmente si está usando algo como AnhkSVN y TortoiseSVN, es posible que los complementos informen como comprometidos (en comparación con lo que el repositorio de Subversion realmente ha confirmado) para no sincronizarse. Si borra archivos o los mueve, considere hacerlo por completo en la línea de comandos (o en TortoiseSVN).
Aprendí a usar el control de la fuente por mi cuenta una vez que estuve trabajando unos años. Mientras comencé con Visual SourceSafe (que fue terrible), eventualmente me mudé a compañías que usaban Subversion y / o TFS para el control de versiones.

Es mucho más probable que pierda el código si no usa el control de código fuente que si lo hace. Definitivamente estás empezando las cosas con el pie derecho.