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

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?

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"

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.

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.

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.

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.

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.

¿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.

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.