Mejores prácticas mercuriales: ¿Succión en función/tarea?

Question

Acabo de cambiar a Mercurial desde SVN. He hecho algunas cosas básicas (la importación de mi código, hacer commits, obtener el truco de log/commit/revert/etc.) Y leer algunos tutoriales sobre la bifurcación/fusión.

Mi pregunta ahora es: ¿Cuál es la mejor manera ("mercurial") para usar Mercurial " no quiero seguir paradigmas SVN; quiero hacer las cosas de la manera 'correcta'

?. Debo mencionar que soy el único desarrollador en la mayoría de mis proyectos, y estoy usando prácticas de agile/scrum. Tal vez mi pregunta realmente debería ser ¿Debería clonar/ramificar por función? ¿Por tarea? Recuerdo haber leído eso este debería ser el caso de Git, y esto le permite básicamente mantener múltiples copias trabajando al mismo tiempo y separar las características frente a las correcciones de errores vs. lo que sea (es decir, mantenga su copia de trabajo separada para cada cosa diferente que esté haciendo) . Y también es aparentemente p arte de Mercurial's best practices.

O podría simplemente conservar una copia, hacer los cambios y comprometerme prolíficamente. Lo que sea.

Si esta pregunta es demasiado subjetiva, no me importa cerrarla, siempre que alguien me pueda vincular a algunos materiales de lectura en cómo usar Mercurial. Eso es lo que estoy buscando.

Answer 1

Hablando como desarrollador (en su mayoría) solo, creo que mi respuesta es ... sí. Cuando sé que estoy haciendo un cambio rápido lo hago en mi directorio de desarrollo "principal", pero si tengo alguna duda sobre cuánto tiempo/algo será complicado, me ramifico desde el principio. Lo bueno es que realmente puedes hacerlo de cualquier manera (y en cualquier orden) que funcione para ti. Si estás trabajando en tu directorio principal de desarrollo en un mod longish y alguien entra y necesita una solución rápida ahora, solo clona el maletero, arréglalo, ¡y Bob es tu tío!

Miro hacia atrás en mis días con SCCS/RCS/CVS con tristeza.

Estoy a punto de llevar a 3 diseñadores a la Tierra Prometida. Son de la vieja escuela y han estado usando Dreamweaver en directorios compartidos (¡el horror!) Durante años. Este fin de semana los estamos trasladando a un mundo de XAMPP, TortiseHG, rsync y deve/staging/production.

Actualización: Formulé mi respuesta de una manera muy ambigua. Gracias por llamarme al respecto, Michael E.

Mi "directorio principal de desarrollo" es en realidad un clon de producción maestro. Cuando digo "rama" quiero decir que voy a estar trabajando en algo por un tiempo, a menudo durante varios días a un mes o más, pero sigue siendo un clon de "algo". Sé que suena vago, pero a veces estoy trabajando con otros desarrolladores y estamos pasando cosas de un lado a otro y simplemente no nos preocupamos demasiado por la fusión al tronco hasta que es hora de ir a la puesta en escena. (Y aun así a menudo es bastante sencillo.)

Así que una "solución rápida" para mí significa actualizar mi "principal" dev dir a troncales, piratería, pruebas, empujar a la puesta en escena en la máquina principal (y prueba) y luego presione para producción (y prueba).La mayoría de las veces, las soluciones rápidas se realizan como una sucursal anónima.

Por cierto, la clonación en un repositorio local es tan rápida que no hay ninguna razón (en mi opinión) para hacer otra cosa. Tengo un proyecto mediano con algo más de 7.000 archivos y cerca de 4 años de compromisos diarios de 4 desarrolladores: el repositorio es de aproximadamente 200 MB. El tiempo de clonación (en una máquina antigua y lenta en mi garaje) es de 10 segundos. Guardo un clon local del maestro de producción remota y hago fetch'es cada hora con cron. HTH.

Answer 2

guía básica: https://www.mercurial-scm.org/guide/

una guía sobre la ramificación: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

prefiero shelving soluciones rápidas, anonymous branches para los cambios del conjunto de cambios de dos a tres, y la clonación con algo más grande que eso.

Answer 3

Siga este enlace. http://hginit.com/

Joel Spolsky explica claramente la diferencia entre el VCS heredado centralizado y un DVCS.

También lo guía a través de los pasos para familiarizarse con el flujo de trabajo mercurial, proveniente del fondo de subversión.

Answer 4

No. En lugar de una rama, quisiera clonar el directorio/repositorio de trabajo para una rama de características.

Estoy siguiendo la excelente descripción en a-successful-git-branching-model.

Tenga en cuenta que el artículo al que se hace referencia es para git no para hg. Sin embargo, el modelo de ramificación es universal, solo la sintaxis entre git y hg difiere.

[actualización 2013-01-31] ​​ Gracias @Alex por su comentario. No estaba al tanto del differences between hg and git. ¿Hay alguien con experiencia en hg que pueda verificar que el modelo de ramificación de git es aplicable a hg o necesita modificaciones para trabajar con hg (excepto la sintaxis de línea de comando)?

Answer 5

He encontrado que las ramas con nombre son preferibles a la clonación en un par de casos. Si la configuración del proyecto que no está marcada en la fuente lo controla, la clonación requiere que copie estas configuraciones en todos mis clones. La mayor parte de mi trabajo está en Django, donde tener un local_settings.py que no está en control de fuente es una expresión común. También encuentro que compartir clones no es tan fácil como compartir ramas con nombre. Si soy el único desarrollador que trabaja en una función, entonces la clonación está bien. En el momento en que necesito que alguien me ayude con una función, una sucursal con nombre habría sido la mejor opción.

@ k3b mencionó gitflow y hay un complemento de hg en desarrollo para hacer lo mismo en hg que usa ramas con nombre. https://bitbucket.org/yinwm/hgflow/wiki/Home