Técnicas avanzadas de subversión, ¿qué me estoy perdiendo?

Comencé a usar SVN hace unos 9 meses y, por decir lo menos, ha cambiado las reglas del juego. Aunque, siento que todavía estoy un poco perdido. Siento que hay mucho más que necesito aprovechar para acelerar realmente el desarrollo de mi aplicación.

Por ejemplo

Me gustaría poder poner en cuarentena cualquier cambio volátil / importante en algún tipo de 'sub-repositorio' o algo así. Estoy descubriendo que los cambios importantes impiden pequeñas correcciones de errores que son bastante urgentes. ¿Cómo puedo enviar una actualización simple sin presionar código incompleto o roto?

Para abordar su ejemplo, tiene tres posibilidades para hacerlo:

1. Puede confirmar archivos individuales. Si usa un IDE para acceder al Repositorio, lo más probable es que tenga una vista para seleccionar o deseleccionar archivos individuales antes de confirmar. En la línea de comandos, escriba svn commit file1 path1/file2 path2para confirmar el archivo1, la ruta1 / archivo2 y cada cambio en la ruta2.
2. Puedes hacer diferentes copias de trabajo. Trabaja en su función grande en su copia de trabajo estándar y obtiene la información sobre el error urgente. Puede retirar su repositorio en un directorio diferente y corregir el error en esta segunda copia de trabajo. Incluso puede consultar solo un subdirectorio con el componente donde se produce el error. Después de la corrección de errores, puede confirmar en su segunda copia de trabajo sin comprometer su trabajo en la gran característica. EDITAR: Esa manera también se describe en la respuesta de Anna Lear.
3. Usted crea una rama para el trabajo en su función. Para eso usa el comando copiar. Si se utiliza el estándar de diseño para su repositorio (directorios con el projectname y subdirectorios con los nombres tronco, las etiquetas y ramas, tronco que contiene el proyecto) puede utilizar la copia-svn comando como el siguiente para crear la rama: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Ahora puede cambiar su copia de trabajo a la nueva ubicación: svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. Si cambia en modo de corrección de errores, confirma sus cambios reales, cambia su copia de trabajo de nuevo a troncal, arregla el error y confirma, y ​​vuelve a cambiar la copia de trabajo a su rama de características. Si está listo para desarrollar la función, puede fusionarla nuevamente con el tronco.

Para el caso simple descrito, generalmente usará el n. ° 1 (lo uso con mayor frecuencia), a veces el n. ° 2. Trabajar con ramas (caso # 3) es más complicado ( leer más ), pero permite más trucos. Pero ramas que coinciden con su descripción de un subrepositorio.

Además de tu ejemplo no puedo decir mucho. Hay muchas cosas sobre Subversion, pero no sé lo que ya usa y lo que necesita para su proyecto. Para aprender más sobre SVN, el SVN-Book es un gran recurso: http://svnbook.red-bean.com/

Puede verificar el código en diferentes entornos limitados en lugar de simplemente tomar una copia y hacer todos los cambios allí.

Entonces, podría tener una estructura de carpetas que se parezca a esto:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

etc.

Todos ellos se pueden retirar desde la misma ubicación en su SVN, por ejemplo http://mysvnrepo/trunk.

De esta forma, puede comprometerse desde su entorno limitado de corrección de errores sin afectar los de desarrollo de características, aunque deberá ejecutarlo svn updatedesde otros entornos limitados para obtener los cambios confirmados para la corrección de errores.

¿Has mirado a Subversion Branches en absoluto?

Una técnica común es mantener estable su Troncal, aplicando soluciones críticas según sea necesario. Luego crea una rama para cada nuevo trabajo significativo. Los desarrolladores que trabajan en ese proyecto revisan la sucursal y se comprometen con la sucursal. No afecta al Troncal hasta que decida fusionar la rama nuevamente con el tronco principal como parte de su integración final.

Otro enfoque es tener una rama para una versión en particular, para evitar cualquier otro trabajo que se realice accidentalmente en el tronco que causa problemas. Puede corregir errores en la 'Rama de lanzamiento' según sea necesario y luego doblar esas correcciones de nuevo al tronco cuando esté listo.

Sus desarrolladores pueden tener varias copias de trabajo desprotegidas, el tronco y cualquier rama, o pueden intercambiar entre el tronco y una rama particular con el svn switchcomando.

No recomiendo tener muchas copias de trabajo de 'sandbox' que guarde por separado, ya que (a) esto prohíbe la colaboración con otros y (b) será demasiado fácil cometer accidentalmente cambios que no funcionan pero aún en el tronco principal.

El tamaño actual de mi copia de trabajo es de 10 GB, con más de 50,000 archivos. Puedo tener varias copias para diferentes ramas, ¡pero lleva un tiempo crear la nueva copia!

Cuando llega un error urgente, generalmente guardo todos mis cambios en un parche, revierto todo, trabajo en el error y me comprometo, luego aplico el parche que guardé ... Mucho más fácil y rápido que obtener una copia de trabajo nueva. Si tuviera que hacer esto a menudo, tendría dos copias de trabajo: una para cambios a largo plazo, la otra para la corrección de errores.