Trabajo en una empresa donde creamos muchas pequeñas aplicaciones específicas para clientes. Somos pocos desarrolladores pero la mayoría de las veces solo hay un desarrollador por proyecto.¿DVCS (Mercurial) no es para mí?
Customer1
ProjectX
App
Tests
ProjectY
App
Tests
Customer2
Project2
Products
Product1
Common
Hoy todo se almacena en un único repositorio.
El proceso es simple.
- Un desarrollador adquiere un nuevo proyecto para un cliente
- Crear una nueva carpeta para el proyecto
- Código en el nuevo proyecto
- hacer algo de mantenimiento en otro proyecto
- Fecha de cambios a mantenimiento proyectar
- Más trabajo en el nuevo proyecto
- Comprobar en el nuevo proyecto
- Entrega al cliente
No hay etiquetado ni bifurcación. Las versiones anteriores se revisan según la fecha.
Este proceso ha servido bien durante muchos años, pero hay algunos puntos de dolor con la herramienta actual (CVS)
- lenta. El proceso de pago lleva minutos, incluso si nada ha cambiado. El historial se almacena en el servidor, por lo que diffs lleva demasiado tiempo
- Agregando nuevos proyectos. Si trabajó con CVS, sabrá que es como: agregar carpeta, agregar archivos en la carpeta, agregar la siguiente carpeta ...
- No hay forma de evitar errores obvios (verificar binarios, etc.)
- No admite el cambio de nombre lo cual hace refactorización necesaria aún más dolorosa.
He usado Mercurial en privado por un tiempo y me gustaría extenderlo a todos los desarrolladores.
Podría haberlo entendido mal, pero hay algunas cosas que no entiendo cómo implementar en nuestra organización.
CVS commits son solo carpetas actuales pero en mercurial son de amplio repositorio. En nuestro caso, significa que el mantenimiento del trabajo de mantenimiento en una carpeta también comprometerá aún cosas sin terminar en otra carpeta. (supongo que podríamos hacer en hg ci ./** modificados carpetas, pero esto no está permitido en combinación, al menos eso es lo que dice la documentación If you are committing the result of a merge, do not provide any filenames or -I/-X filters.)
La práctica común en Mercurial es tener un repositorio por proyecto.
Un repositorio por proyecto está bien para nosotros, pero crea otros problemas como:
Cómo gestionar múltiples repositorios en el servidor central?
Si un desarrollador crea un nuevo proyecto, eventualmente necesitará impulsar sus cambios.Sólo haciendo
hg push http://localhost:8000/Customer1/NewProject
bloquea el hg-servidor web con un volcado de pila feo y cuelga el cliente.
La manera en que yo entiendo es que el desarrollador necesita acceso al shell del servidor para añadir el nuevo repositorio a un archivo de configuración y reinicie hgweb
La alternativa es utilizar SSH o una parte (¿Hay beneficios usando SSH en lugar de un recurso compartido de archivos?)
cd Customer\NewProject
hg init
hg clone --noupdate --pull . //mercurialshare\Customer\Project
echo "[paths]" >.hg\hgrc
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc
hg push
obras, pero es un poco complicado para algunos de los desarrolladores
todos los desarrolladores necesitan tener todos los proyectos.
(En realidad, no todos pero muchos proyectos están vinculados por lo que deben estar presentes y lo más fácil es simplemente tener todos)
Con muchos proyectos existentes y nuevos agregados semanal necesitamos una manera de tirar de todos los proyectos en un solo ve y también clona nuevos.
Estaba pensando que subrepos podrían resolver el tirón "global", pero el la línea siguiente en la documentación es un sensacional
"Cuando nos comprometemos, Mercurial tratará de crear una imagen coherente del estado de la totalidad project y sus subrepos. Hace esto al intentar primero confirmar en todos los subrepos modificados y luego registrar el estado de todos los subrepos ".
Volviendo al problema del repositorio único de confirmaciones globales.
(intentado algunas variantes de hg ci .hgsub .hgsubstate <subrepo> pero .hgsubstate parecen ser actualizado sólo en confirmaciones completos. Los demás usuarios no podrán ver los cambios del proyecto sin una explícita hg pull --update en la carpeta del proyecto)
Mi pensamiento actual es tener una archivo por lotes en la raíz que extrae todos los proyectos
¿Alguna otra idea sobre cómo usar mercurial en nuestra organización?
Editar
Gracias por la respuesta. Actualmente estoy evaluando cómo un repositorio por proyecto funcionará para nosotros. Pongo un archivo por lotes en el nivel superior
FOR /F %%x IN (repolist.txt) DO (
If EXIST .\%%x\.hg (
ECHO Pull %%x
hg pull --update --repository .\%%x
) ELSE (
ECHO Clone %%x
mkdir .\%%x
hg clone --pull %1\%%x .\%%x
)
)
["El hecho de que pueda usar un DVCS de forma distribuida no significa que deba hacerlo"] (http://stackoverflow.com/q/3854611) –