En el control de versiones centralizado, ¿siempre es bueno actualizar a menudo?

9

Asumiendo que:

  • Su equipo está utilizando el control de versiones centralizado.
  • Está trabajando en una función más grande que tardará varios días en completarse, y no podrá comprometerse antes porque rompería la compilación.
  • Los miembros de su equipo comprometen algo todos los días que podría cambiar algunos de los archivos en los que está trabajando.

Como se trata de un control de versión centralizado, tendrá que actualizar su pago local en algún momento: al menos una vez justo antes de confirmar la nueva función.

Si actualiza solo una vez justo antes de su confirmación, puede haber muchos conflictos debido a los muchos otros cambios realizados por sus compañeros de equipo, lo que podría ser un mundo difícil de resolver de una vez.

O bien, puede actualizar a menudo, e incluso si hay algunos conflictos que resolver día a día, debería ser más fácil hacerlo, poco a poco.

¿Te quedarías, siempre es una buena idea actualizar a menudo?

janos
fuente
16
Si no se están diversificando, entonces usted no está tomando ventaja de uno de los mayores beneficios de una versión del sistema de control.
gahooa
¿Su CVCS proporciona una vista conveniente de posibles conflictos de actualización sin modificar sus archivos locales? TortoiseSVN tiene tal funcionalidad.
rwong
@gnat la pregunta es con qué frecuencia actualizar, no confirmar
janos
2
La pregunta es muy específica acerca de con qué frecuencia "actualizar". Y ya es parte de las suposiciones que sus compañeros de equipo realmente cometen a menudo. Lo que seguramente es algo bueno, pero en cualquier caso no es el tema aquí.
janos

Respuestas:

24

Personalmente, actualizo mis versiones locales diariamente.

En el escenario que describe, yo iría más allá

  • Crear una rama para la nueva característica larga.
  • Combinar a menudo desde la línea principal a esta nueva sucursal.

De esta manera,

  • Puede registrarse diariamente para conservar su código en el servidor
  • No tiene que preocuparse por romper la compilación al registrarse.
  • Puede usar el repositorio para deshacer algún trabajo o diferencia cuando sea necesario con registros anteriores.
  • Seguro que estará trabajando en la última base de código y detectará posibles cambios de código conflictivos desde el principio.

Los inconvenientes como los veo son

  • La fusión de main debe hacerse manualmente (o con guión)
  • Se necesita más "administración"
Lieven Keersmaekers
fuente
2
Tienes razón en que siempre es bueno trabajar en ramas de características en lugar del tronco. El problema es que la mayoría de CVCS hace un mal trabajo en la fusión, por lo que la mayoría de los programadores que conozco en CVCS se adhieren a una sola rama la mayor parte del tiempo. La pregunta es, ¿puede decirles que en general siempre es bueno actualizar a menudo?
janos
66
Viniendo de Sourcesafe (donde no nos fusionamos en absoluto) a TFS, git y mercurial (donde nos fusionamos a menudo) , mi experiencia personal es que la fusión a menudo crea muchos menos problemas que esperar una fusión de Big Bang. Estoy de acuerdo en que requiere un cambio mental de otros programadores. Estoy sonando como un disco rayado en mi lugar de trabajo, pero todos deberían comprometerse a menudo y actualizarse a menudo.
Lieven Keersmaekers
6

Sí, es una buena idea actualizar a menudo. Actualiza a menudo para evitar conflictos de fusión difíciles y esto es lo básico del conocimiento de la Gestión de configuración de software (SCM) con el problema de los cambios divergentes.

Esto es independientemente de si está centralizado o distribuido; cuanto más tiempo se desvíe de una fuente aguas arriba (es decir, si es un enlace troncal, una rama u otro repositorio en el caso de DVCS), mayor será la posibilidad de conflictos de fusión. Sí, pueden surgir sorpresas desagradables de su equipo al actualizar, pero posponer la desagradable sorpresa es aún peor (cuanto más espere, menos personas recordarán por qué se hicieron una serie de cambios).

Para que la actualización funcione, esto también significa que usted y otros programadores que trabajan en código nunca deben comprometer o empujar a sabiendas código ascendente que interrumpe la compilación . Por lo general, esta es la razón por la cual los programadores se ramifican (o se desvían de la corriente arriba en términos de SCM), para proteger a los miembros de su equipo y otras partes interesadas de tener un código roto si tal situación inevitablemente surgiera.

El mantra que puedes usar para recordar es este: "actualizar, actualizar, actualizar, confirmar". Siempre asegúrese de que sus cambios funcionen con otros antes de comprometerse. Esto también es para asegurarse de que el código de verificación por primera vez también funcione.

Spoike
fuente
4

El tercer punto en la pregunta es simplemente incorrecto :

  • Está trabajando en una nueva característica que seguramente llevará varios días completar, y no podrá comprometerse antes porque rompería la compilación.

Si sabe que va a estar trabajando en algo que no puede comprometerse durante algún tiempo, ese es el ejemplo de libro de texto para usar ramas.

No te pongas en la situación en la que tienes muchos cambios pendientes. Si sabe que no podrá comprometerse en la rama principal de su proyecto durante algún tiempo, trabaje en otra rama. Y allí, comprométete a menudo .

Si ya está en la situación descrita en la pregunta, cambie a una rama ahora mismo , confirme los cambios y continúe trabajando en esa rama.

Normalmente en CVCS es una buena idea actualizar a menudo. Pero si está trabajando en una sucursal, la cuestión de "actualizar a menudo o no" se convierte en "fusionar a menudo o no". Y la respuesta es sí de todos modos. Solo asegúrese de confirmar todos los cambios pendientes (en la rama) antes de fusionarse desde otra rama, a su opción de revertir la fusión de manera segura si es necesario.

janos
fuente
2

Creo que deberías comprometerte más a menudo. Si va a trabajar durante mucho tiempo, como unos pocos días, debe ramificar su código y trabajar en su sucursal en lugar de trabajar directamente en la troncal. Sé que es conveniente comenzar a trabajar sin sucursales, pero no es realmente flexible ya que no puede estar seguro de que su actualización / confirmación romperá su código o no, lo que termina en la situación de que mantendrá su actualización / confirmación hasta que haya hecho tu trabajo La "ramificación de características" es mejor en la forma en que siempre puede confirmar su código, y simplemente volver a fusionarse más tarde cuando termine.

En la estrategia de ramificación, la actualización se reemplaza con la fusión desde el tronco. Según mi experiencia, no es necesario fusionarse desde el tronco con tanta frecuencia, ya que el código en un lapso de tiempo de cinco días no cambiaría mucho y es más fácil resolver el conflicto una vez solo cuando haya terminado.

tia
fuente
1

De hecho, me parece más conveniente usar un control de versión distribuido localmente. Es decir, uso git como cliente de subversión. Esto tiene las ventajas de que:

  • Los cambios locales se guardan antes de actualizar, por lo que si me equivoco en la fusión, siempre puedo volver y volver a hacerlo.
  • Al hacer cambios más grandes, puedo guardar las partes que están terminadas. Eso facilita la revisión de los cambios restantes en progreso.
  • Cuando soluciono un error durante un trabajo más grande, puedo confirmar solo esa solución, comprometer temporalmente el resto y "dcommitir" la solución a subversion mientras mantengo el otro trabajo en progreso local.
Jan Hudec
fuente
0

Si está agregando una nueva función, ¿podría crear un nuevo archivo de origen único (y un archivo de encabezado de interfaz externa correspondiente)?

¿Me preocupa que una "nueva característica" tenga implicaciones generalizadas? La orientación a objetos puede que ya no sea la palabra de moda que alguna vez fue, pero ese paradigma tiene mérito.

De esa manera, podría crear el marco (interfaz externa, más funciones de código auxiliar) y confirmar que debería haber un mínimo de efectos de terceros, mientras termina el resto de su desarrollo.

En la situación que describe, creo que es mejor tener más archivos fuente más pequeños que menos archivos más grandes.

Andrés
fuente
0

¿Cómo es diferente para un control de versión centralizado que para uno distribuido?

En ambos casos, tendrá que registrarse en un lugar cuyo contenido se haya movido en comparación con lo que comenzó. No veo ninguna diferencia en la frecuencia de fusión desde el repositorio central hasta su lugar de trabajo (y su rama de proyecto es su lugar de trabajo).

Tiendo a fusionarme a menudo (al menos una vez al día, también puedo fusionarme en otro momento conveniente para mí, o cuando sé que alguien ha registrado algo que afecta lo que estoy trabajando). Es mucho más fácil absorber pequeños cambios y si tiene un problema, las personas son más útiles cuando les pregunta sobre lo que acaban de registrar que sobre lo que hicieron hace una semana.

Por cierto, no sé lo que llamas "romper la compilación". Tiendo a trabajar en incrementos relativamente pequeños, de modo que mantengo un estado compilable, incluso si rompe algunas características. Y ejecuto las pruebas para saber que la fusión no ha roto algo que debería funcionar. Nuevamente, es más fácil solucionar un problema cuando se detecta temprano.

Un programador
fuente
2
En la versión distribuida, puede confirmar sus cambios pendientes localmente. De esa manera, si una fusión genera demasiados conflictos y prefiere posponerla y revertir, puede hacerlo. En el control de versiones centralizado no puede confirmar localmente, y si desea revertir una actualización, no puede hacerlo. Por lo tanto, el matiz centralizado de la versión es importante, porque la operación de actualización es más arriesgada que una fusión.
janos
3
@janos, en mi experiencia, cuanto más difícil sea la fusión, más querrás hacerlo ahora, ya que esperar nunca lo hará más fácil. Por lo general, hojeo los diferenciales antes de aplicarlos y, a veces, hago una copia de seguridad manual si parecen complejos. Lo que también hice fue usar un repositorio mercurial para controlar la versión de los cambios que no pude registrar en el sistema oficial. No encontré que los beneficios justificaran el costo en mi situación, pero puede ser diferente para los suyos.
Programador
la operación de actualización en CVCS es menos segura porque no puede revertirla de la misma manera que puede revertir una fusión en DVCS. Esta es la razón por la cual la parte CVCS es significativa, y la pregunta tendría poco sentido en un DVCS.
janos
Esperar no puede disminuir la dificultad ni el riesgo, por lo que está argumentando por actualizaciones más frecuentes.
Programador
Sí, siempre pensé que es bueno actualizar a menudo. Quiero validar eso buscando cosas malas que tal vez no piense en mí mismo. Por ejemplo, si tiene un refactor pendiente grande, entonces tal vez no quiera que incluso pequeños conflictos exploten en su cara. No lo sé. Solo quiero asegurarme de que puedo continuar diciendo "actualizar a menudo" sin hacer una tontería.
janos
0

Depende de lo bueno que seas en "no actualizar" cuando alguien más rompa la compilación. Por un lado, desea actualizar en fragmentos tan pequeños como sea posible. Personalmente, actualizo casi cada vez que noto que hay actualizaciones disponibles. Por otro lado, si la compilación se rompe y va a tomar un día para que otra persona la arregle, aún así podrá trabajar en su nueva función mientras tanto.

He trabajado con sistemas de control de versiones que son muy difíciles de respaldar una vez que se realiza una actualización. En esos casos, tiendo a actualizar solo justo antes de tener que registrarme. Con mejores sistemas de control de versiones, hay pocas razones para no actualizar varias veces al día.

Karl Bielefeldt
fuente