DVCS trabajando en server remoto

Mi lugar de trabajo está considerando cambiar a un moderno (D) VCS, que es algo que estoy presionando.

Mi jefe está de acuerdo con la idea y el flujo de trabajo actual sería tener un repository centralizado donde todos puedan comprometer / fusionar sus cambios cuando se realice una tarea. Mientras trabajan en una tarea, cada desarrollador puede tener su propia twig para trabajar y comprometerse a .

El problema es que no le gusta mucho la idea de que las personas tengan código en sus estaciones de trabajo solo hasta que los cambios se envíen al repository compartido. Esto se debe a fallas de disco, etc.

Lo que le gustaría ver es que todos tuvieran su propia sucursal en el server que se actualizaría automáticamente cuando se comprometa en su estación de trabajo local.

¿Hay algún DVCS compatible con esto de una manera fácil de configurar?

Sin embargo, tenga en count que personalmente creo que es perfectamente aceptable que cada desarrollador asum la responsabilidad de respaldar su código, por ejemplo, simplemente presionando sus cambios a una twig privada en el server remoto. Esto podría hacerse manualmente o automáticamente con un script cron.

Solo por el factor "nosotros también": esto es factible en mercurial como en bzr y git. Solo use un enlace de confirmación que empuja a un repository más central cuando esté disponible. Algo como esto:

[hooks] commit = hg push ssh://path/to/individual/developer/repo 

Una cosa que señalaré es que, en lugar de imponer esto a través de los enganches, puede hacer que impulsar al repo central sea atractivo para los desarrolladores individuales y descubrirá que lo hacen por sí mismos. Cosas que he hecho para lograr que las personas se comprometan / presionen (diariamente / por hora):

  • asegúrese de que tengan un repository al que puedan acceder sin expectativas sobre la compilation / aprobación de testings: un informe de punto de control si lo desea
  • facilitarles la creación de una compilation de continuous integration de repositorys de su elección en el server central; si hay tres clics, es fácil para ellos comenzar el build-on-change para sus twigs personales, entonces continuarán presionando cada cambio solo para ver ejecutar el set de testings
  • no los avergüence por tener un historial complicado: un buen uso de DVCS implica una gran cantidad de ciclos de extracción / fusión / inserción. Si haces que usen rebase o queuepsen para convertir 30 sets de cambios con 15 fusiones en un set de cambios por característica / error, entonces se les incentiva para mantener la cosa local hasta que estén listos para tirar / fusionar / empujar todo al mismo time
  • ejecutar algunas métricas sin prejuicios en un lugar público. Nada draconiano y tonto como clasificar desarrolladores por líneas de código, pero algo que se puede notar, ya sea un feed RSS agregado de todos los feeds RSS repo, o un commit @ alias de correo electrónico que obtiene un rápido "X insertó el set de cambios Y en el repository Z "post cada vez que alguien empuja. Eso es bueno porque a la gente siempre le gusta un poco de sol en sus horas extras trabajadas y un "empujón" al final de la session lo consigue.

Puede preparar un .git/hooks/post-commit.sample posterior a la confirmación (ver .git/hooks/post-commit.sample en su repository local) para enviar automáticamente la twig actual al server.

Si haces esto, creo que los nombres de las sucursales en el server compartido deben tener un prefijo con el nombre del desarrollador para evitar conflictos de nombres.

Esto suena bastante similar a la configuration que tenemos con Bazar en este momento, pero creo que se puede replicar en Mercurial y otros usando ganchos post-commit en Git o "push-after-commit" en Mercurial. La forma de hacer esto en Bazar sería hacer algo como esto:

 # Create a repository bzr init-repo --no-trees path/to/server/project # Create the main development branch bzr init path/to/server/project/trunk # Create the local working copy (which contains the complete history but is bound to the server copy of trunk) bzr co path/to/server/project/trunk working-directory-name # Alternative command that works the same: bzr branch --bind path/to/server/project/trunk working-directory-name cd working-directory-name # Now create a branch for the user to work on bzr switch -b new-branch # Hack hack hack # Commit (gets pushed to server as this is a checkout aka bound-branch) bzr ci -m "Done stuff" # Go back to trunk to merge bzr switch trunk # Merge bzr merge path/to/server/project/new-branch # Commit the merge changes (gets pushed to server) bzr ci -m "Merged new-branch" 

Todas las sucursales se llevarán a cabo en un repository en / path / to / server / project. Cualquier compromiso con la copy de trabajo local se enviará al server automáticamente. Si usa GUI, puede instalar mi complemento remote-feature-branches , que automatiza el process de crear un nuevo repository con una twig de enlace troncal y verificarlo localmente (los primeros tres commands anteriores).


Solo he usado Mercurial un poco, pero creo que la forma en que harías esto sería tener una twig en el server y bifurcarla localmente y editar el file .hgrc para include:

 [hooks] commit.autopush = hg push 

Todos los usuarios tendrían una copy local que contiene todas las twigs en este caso, mientras que en Bazar, la copy local solo tendría el historial de la sucursal en la que estaban trabajando. Implementaciones ligeramente diferentes, pero funcionalmente más o less lo mismo, creo.

Parece que su jefe está trabajando para la capacidad de tener un DVCS pero también quiere tener un SCM centralizado mientras trabaja "en la oficina".

Eso es correcto, entonces ¿por qué no echas un vistazo a Plastic SCM? Eso es exactamente lo que hacemos: puedes ir distribuido o (más "amigable para la empresa") puedes trabajar centralizado (o una combinación de los dos. Y todavía se trata de ramificarse.

Eche un vistazo a estos dos artículos:

http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

Y tal vez aquí también: http://www.plasticscm.com/features/task-driven-development.aspx