control de origen de las mejores prácticas - actualizando periódicamente su copia de trabajo desde el repositorio

Question

. (Nota: Esta pregunta no es específico de la subversión - Sólo estoy usando aquí como un ejemplo)

Sé que el "svn update "comando (o lo que sea que el comando similar está en otros sistemas) actualizará su copia de trabajo con cualquier cambio a los archivos del repositorio. También sé que es una mejor práctica en el control de fuente realizar periódicamente una actualización de svn para asegurarse de tener el conjunto de cambios más reciente antes de comprometer (registrar) esos cambios.

Un enfoque alternativo a esta mejor práctica (quizás sería una peor práctica:>) sería administrar conflictos potenciales solo en el momento del compromiso (check-in), en lugar de hacerlo periódicamente durante el período editando el archivo.

Parece que la mejor práctica es adoptar un enfoque "pesimista" de la gestión temprana e inmediata de los conflictos, frente a un enfoque "optimista" de gestionar los conflictos solo en el momento del compromiso y gestionar todos los conflictos acumulados en ese momento.

¿Declaro correctamente la intención de la mejor práctica frente a la alternativa?

Answer 1

Personalmente actualizo mi copia de trabajo todos los días cuando comienzo a trabajar. Encuentro que los conflictos se encuentran temprano y se resuelven rápidamente de esa manera.

Answer 2

Sí, es bueno ser pesimista. Más temprano, pequeños cambios, menos integrales son más fáciles para

• A. automerges de SVN (o de TFS o lo que sea) y
• B. más fácil cuando se tiene el ser humano para resolver los conflictos.

Por supuesto, depende de cuántos otros desarrolladores tengan el mismo código y de la probabilidad de que estén trabajando con el módulo en el que está trabajando. (Actualmente soy el único que trabaja mi proyecto, por ejemplo. No actualizo casi tan seguido como cuando hay otros también).

Answer 3

Suena bien. Por supuesto, si se compromete a menudo en lugar de esperar hasta tener un montón de cambios, los dos enfoques equivalen a lo mismo.

Answer 4

Derecho, con el auge de los enfoques de control de versiones distribuidas, ha habido más y más de una tendencia a "quedarse oscuro" como dirían algunos, para irse y trabajar en sus propias cosas y preocuparse de fusionarlo más tarde .

Muchas personas, incluyéndome a mí, dirían que esto da como resultado más conflictos que son más difíciles de resolver, ya que esencialmente estás operando en una rama diferente y, por lo tanto, yendo en una dirección diferente.

Las actualizaciones periódicas aseguran que no se aleja demasiado de los demás, pero muchas otras personas consideran que esto socava la flexibilidad del control de versiones distribuidas.

Answer 5

Hay un punto medio: puede mantener sus cambios en una bifurcación, separados de los cambios de troncales que están en progreso. Esto es súper fácil en git y menos fácil (diría) en subversión. Lo que esto le permite hacer es sacar los cambios de la troncal con regularidad sin "arriesgar" automáticamente los cambios locales que se ven afectados por conflictos con los commits troncales.Creo que esta es la razón por la que no quiere que quiera obtener actualizaciones, es decir, porque no está listo para ellas. Usted sería ver que se han producido cambios, sin embargo, que es algo muy bueno. Tener los cambios en una sucursal separada significa que puede intentar combinar los cambios ascendentes, pero si no coinciden, puede cancelar esa combinación y seguir trabajando un poco en su código hasta que esté listo para realmente gastar el esfuerzo para resolver los conflictos.

Es es definitivamente cierto que cuanto antes realinee su código para que sea compatible con el troncal (mediante svn update o fusionándose en los cambios), más fácil será resolver los conflictos. Es bastante horrible esperar hasta que esté listo para entregar los cambios para descubrir que todo se ha movido de debajo de usted; pasará mucho más tiempo investigando los registros, tratando de descubrir cuáles son los cambios y cómo puede aplicar correctamente. ellos al código que usted ya pensaba que estaba bien, y , entonces necesita tener que volver a probar su código con los nuevos cambios! Si se hubiera estado fusionando todo el tiempo, ya habría probado esta versión.

Answer 6

Creo que todo depende de la cantidad de dependencias en el código y del número de desarrolladores que trabajen en el mismo código al mismo tiempo. Si tiene pocos desarrolladores trabajando en ese mismo código, puede pasar un período de tiempo más largo sin "fusionarse" con el código del repositorio. Personalmente, me gusta esperar hasta el final de mi desarrollo, siempre y cuando no me lleve semanas terminarlo. Si le toma semanas terminar, debe dividir su funcionalidad en partes más pequeñas y usar un enfoque más gradual que le permita verificar su nuevo código y fusionarse con mayor frecuencia.

Answer 7

Otra forma es trabajar en su propia sucursal, no en el baúl. De esta forma, la única fusión se realiza cuando se completa la función/corrección de errores/lo que sea. Nadie más se comprometerá en su sucursal, por lo que está a salvo hasta que haya terminado.

actualización

Answer 8

• cada vez que se sienta delante del ordenador
• actualización antes de cada confirmación

=> años de uso SMC sin problemas.

Answer 9

• Actualiza cada vez que lo necesites. Al menos todas las mañanas Y, cada vez que tus compañeros de equipo te lo dicen. Cada vez que sepa que alguien cometió algo en el área donde trabaja.

• Antes de comprometerse. Nunca alguna vez comprometa algo hasta que haya actualizado a la última versión del repositorio y esté tan seguro como sea posible su compromiso no rompe nada.

Answer 10

Como se mencionó anteriormente varias veces, mi consejo es similar:

• actualización menudo, tanto como sea posible, pero al menos una vez al día, y
• Commit menudo, idem (pero por supuesto debe tener una característica/marcha/probado compilado)

El segundo punto es muy im Portant también: tan pronto como "algo" está funcionando, se debe comprometer, la literatura dice "No te quedes ciego", es decir, no mantenga el desarrollo en su disco duro durante un mes hasta que sea perfecto (nunca lo es de todos modos :-))

Esta es la idea básica detrás de Continuous Integration (un montón de material en el sitio de Martin Fowler y explicaciones muy claras) .

Demasiado últimos puntos:

• En cuanto a "sintácticas" conflictos, no se preocupe por ellos, que son raros y fácilmente fijo,
• En cuanto a " semántica" o "arquitectura "conflictos, es aún más importante descubrirlos lo antes posible, de ahí el lema anterior: actualizar a menudo, comprometerse a menudo, fusionar a menudo (para personas que usan DVCS), y prueba a menudo la función integrada para disco ver esos potenciales conflictos semánticos.

En mi anterior trabajo, algunas personas en los departamentos de productos se niegan a actualizar todos los días (incluso menos varias veces al día), ya que decían: "el tronco se rompe, si actualizo, voy a perder mi día ". ¡Tenían razón! ¡Esto no es aceptable! Es por esto que es muy importante enfatizar que solo el código de trabajo debe ser comprometido (o empujado para personas DVCS): para ayudar a hacer esto configuro compilaciones diarias, que comenzarían en cada confirmación (usando la herramienta de buildbot de software libre) pero existen docenas de herramientas similares). Con las compilaciones y pruebas de confirmación, es más fácil no estar seguro de que el troncal no está roto; cada vez que falla una compilación o una prueba (simple), la (s) persona (s) que ha (n) recibido (n) confirmado (s) recibe (n) un correo electrónico y debe corregir el problema inmediatamente o revertirlo. Y el resumen web (llamado cascada en el vocabulario buildbot) está aquí para que todos lo vean. En resumen, es realmente un estado de ánimo y una confianza mutua para construir entre los desarrolladores, pero una vez que llegas a este punto, créeme, nunca querrás volver: los desarrollos son más rápidos pero coordinados, y las personas están felices de contribuir con el mismo código en lugar de trabajar solo en su estación de trabajo durante un mes. Vale la pena tratar de tomar este camino (en mi humilde opinión).