Bazar: ¿Necesito twigs?

Soy nuevo en VCS y solo estoy tratando de entender cómo usar Bazar para mi situación. Mi situación es que soy un desarrollador web solo que trabaja en un website que consiste en un website en vivo, por ejemplo, www.mysite.com y un sitio de ensayo / desarrollo, por ejemplo, dev.mysite.com. Estoy usando Bazaar Explorer ya que no soy realmente un tipo de línea de command. Solo trabajo desde una computadora principal y cargo los files al server web por FTP. Tengo Bazar instalado en mi computadora con Windows local.

Entonces para comenzar, creé un proyecto de Bazar en mi computadora local. Me quedé con la opción pnetworkingeterminada 'Feature branches' ya que la documentation de Bazarr dice que esto es mejor para proyectos pequeños (pero no entiendo completamente la diferencia entre los models de espacio de trabajo incluso después de leer los documentos). Esto creó una carpeta (que llamé _Source Control) con las subcarpetas trunk y .bzr. Copié todos mis files de proyecto (es decir, los files del website) en el tronco e hice una confirmación inicial.

Ahora mi primera pregunta es si debo trabajar directamente en estos files o ¿necesito hacer otra twig para trabajar?

¿Es este flujo de trabajo un enfoque sensato o hay una forma obviamente mejor ?:

  • Trabajar en algunos files en el tronco principal
  • Transfiera los files actualizados al sitio de ensayo mientras trabajo para verificar errores, funcionalidad, etc.
  • Una vez que he llegado al punto en el que he completado una determinada funcionalidad, confirmo mis cambios
  • Suba la última revisión al website en vivo usando el plugin bzr-upload

Entonces, ¿cómo debo manejar la situación en la que descubro que la última actualización ha presentado un problema y quiero que el sitio vuelva a la revisión anterior? ¿Es así?

  • volver a la versión anterior en Bazar
  • Cargue esta revisión en el website en vivo usando el plugin bzr-upload
  • ¿cómo vuelvo a la última versión para poder solucionar el problema? ¿Es aquí donde necesitaría una sucursal?
  • una vez que haya actualizado los files nuevamente para solucionar el problema, realice un commit y cargue la última revisión en el website en vivo usando el plugin bzr-upload

Y una última pregunta, ¿Checkout es relevante en mi situación?

La opción Feature branches de Bazaar Explorer crea un llamado Repositorio Compartido y una única twig llamada trunk dentro de él (llamada Árbol de Repositorio ). En tu ejemplo:

  • _Source Control == Repositorio compartido
  • _Source Control/trunk == Árbol de repositorys

La idea es que en esta configuration pueda crear varias sucursales junto a la línea trunk , y almacenarán los datos de revisión de manera eficiente, al compartir cosas en el repository compartido, para resumir.

Si eres un principiante, entonces no te preocupes por las twigs. En algún momento, es probable que se te ocurra naturalmente. Por ejemplo, te das count de que quieres hacer algo experimental pero no quieres estropear tu baúl. La solución obvia será crear una sucursal.

Ahora sobre su flujo de trabajo:

  • Creo que puede usar el complemento de bzr upload bzr para el sitio de ensayo y el sitio en vivo.

  • Para revertir su sitio en vivo a una versión anterior, use bzr upload -rREV --overwrite donde REV es la revisión que desea revertir. Usando el --overwrite parece sucio, y probablemente lo sea. Pero esa es la única forma en que funciona para mí, creo que es un error en mi versión del complemento ( 1.0.1dev ), sugiero probar primero sin esa bandera.

  • Para solucionar el error, no hay necesidad de retrotraerlo localmente, solo corrige el error y confírmalo, luego súbelo de nuevo con bzr upload sin los otros indicadores para que el website cumpla la última versión.

Hay muchas forms de trabajar con Bazar. Puede implementar un flujo de trabajo hermoso y sofisticado, o usar este flujo de trabajo algo sucio, pero simple y fácil de entender. Avíseme si tiene más problemas.

Y no, no necesita checkout en la configuration que describió.

En Bazar, una sola twig es una historia lineal de sus files de proyecto. Necesita varias sucursales tan pronto como desee trabajar en múltiples versiones de su proyecto al mismo time. Eso ocurre naturalmente cuando participan múltiples desarrolladores, pero también puede ser útil para proyectos de una sola persona.

Por ejemplo, le permite continuar desarrollando una nueva característica como parte de una twig de características, mientras agrega, testing e implementa correcciones de errores en la twig principal. Una vez que la function ha finalizado, puede fusionarse nuevamente en la twig principal. Del mismo modo, si desea experimentar con algo que puede o no querer tener como parte de su base de código principal, es una buena idea tener una twig experimental para eso.

Para proyectos simples, una sola twig principal puede ser todo lo que necesita, pero es una buena idea familiarizarse con la ramificación independientemente, ya que tiene una serie de casos de uso muy prácticos.

Para tratar el escenario de "problema" que describe: Primero, obtenga la última revisión de trabajo que tenga. Hay una serie de forms de lograr eso:

  • bzr checkout se puede utilizar para crear una nueva salida de una twig específica y una revisión en un directory de trabajo diferente. Luego tiene un directory que contiene la versión anterior y un directory que contiene la nueva versión.
  • bzr branch hace básicamente lo mismo que bzr checkout para este propósito, pero también crea una twig independiente en el nuevo directory basado en la revisión especificada. Esto es útil si, como se describió anteriormente, necesita trabajar tanto en la versión anterior como en la nueva al mismo time.
  • bzr update se puede usar para cambiar el directory actual a una revisión diferente. A continuación, puede hacer lo que quiera para implementar la versión anterior y usar la bzr update nuevamente para volver a la más reciente.