version-control - usados - svn version control

¿Cuál es el uso más inteligente del repositorio fuente que hayas visto alguna vez?

Question

En realidad, esto se debe a mi pregunta anterior, en la que una de las respuestas me hizo preguntarme cómo las personas están usando el repositorio scm / de diferentes maneras para el desarrollo.

Answer 1

¿Mi favorito? Una herramienta inédita que utilizó Bazaar (un DSCM con un manejo de renombrado explícito muy bien pensado) para rastrear datos estructurados en árbol al representar el almacén de datos como una estructura de directorio.

Esto permitió que un documento XML se ramificara y se fusionara, con toda la bondad (detección y resolución de conflictos, flujo de trabajo de revisión y, por supuesto, registro de cambios y similares) facilitado por el moderno control de fuente distribuida. Dividir los componentes del documento y sus metadatos en sus propios archivos evitó que la proximidad creara conflictos falsos y de otro modo permitió que todo el trabajo que el equipo de Bazaar implementara en los árboles del sistema de archivos de versiones funcionara con datos estructurados en árbol de otros tipos.

Answer 2

Definitivamente Polarion Track & Wiki ...

Toda la base de datos de seguimiento de errores y wiki se almacena en subversión para poder mantener un historial completo de revisiones.

http://www.polarion.com/products/trackwiki/features.php

Answer 3

Compromisos probados

Antes (TeamCity, administrador de compilación):

El concepto es simple, el sistema de construcción se erige como un obstáculo entre el commit que ingresa a la troncal y solo después de que el sistema de compilación determina que la confirmación no interrumpe las cosas, permite que la confirmación se introduzca en el control de versiones, donde otros desarrolladores sincronizarán y integrar ese cambio en sus copias locales de trabajo

Después (usando un DVCS como Git, que es un repositorio fuente):

Mi flujo de trabajo con Hudson para compromisos probados previamente implica tres repositorios Git separados:

• mi repositorio local (local),
• el repositorio canónico / central (origen)
• y mi repositorio "público mundial" (dentro del firewall).

Para confirmaciones probadas previamente, utilizo una rama en constante cambio llamada "pu" (actualizaciones potenciales) en el repositorio legible en todo el mundo.
Dentro de Hudson creé un trabajo que sondea el repositorio (público) legible por el mundo para los cambios en la rama "pu" y dará inicio a las compilaciones cuando se empujen las actualizaciones.

mi flujo de trabajo para tomar un cambio desde el inicio hasta el origen es:

* hack, hack, hack
* commit to local/topic
* git pup public
* Hudson polls public/pu
* Hudson runs potential-updates job
* Tests fail?
o Yes: Rework commit, try again
o No: Continue
* Rebase onto local/master
* Push to origin/master

Utilizando este flujo de trabajo de prueba probado previamente, puedo descargar la mayoría de mis requisitos de prueba al conjunto de máquinas del sistema de compilación en lugar de ejecutarlos localmente, lo que significa que puedo pasar la mayor parte del tiempo escribiendo código en lugar de esperar que las pruebas se completen por mi cuenta. máquina entre iteraciones de codificación .

(Variación) Private Build (David Gageot, Algodeal)

Mismo principio que el anterior, pero la compilación se realiza en la misma estación de trabajo que la que se usó para desarrollar, pero en un repositorio clonado:

¿Cómo no usar un servidor de CI a largo plazo y no sufrir el aumento del tiempo perdido mirando las compilaciones localmente?

Con git, es pan comido.
Primero, ''clonamos'' el directorio de trabajo en otra carpeta. Git hace la copia muy rápido.
Los próximos tiempos, no necesitamos clonar. Sólo dile a Git obtener los deltas. Resultado neto: clonación instantánea. Impresionante.

¿Qué hay de la consistencia?
Haciendo un simple '' git pull '' desde el directorio de trabajo se dará cuenta, utilizando los compendios del delta, que los cambios ya se realizaron en el repositorio compartido.
Nada que hacer. Impresionante de nuevo.

Por supuesto, mientras la compilación se ejecuta en el segundo directorio, podemos seguir trabajando en el código. No hay necesidad de esperar

Ahora tenemos una compilación privada sin mantenimiento, sin instalación adicional, que no dependa del IDE, se ejecutó con una sola línea de comando. No más construcciones rotas en el repositorio compartido. Podemos reciclar nuestro servidor CI.

Sí. Has escuchado bien. Acabamos de construir un CI sin servidor. Cada característica adicional de un servidor de CI real es un ruido para mí.

#!/bin/bash
if [ 0 -eq `git remote -v | grep -c push` ]; then
REMOTE_REPO=`git remote -v | sed ''s/origin//''`
else
REMOTE_REPO=`git remote -v | grep "(push)" | sed ''s/origin//'' | sed ''s/(push)//''`
fi
if [ ! -z "$1" ]; then
git add .
git commit -a -m "$1"
fi
git pull
if [ ! -d ".privatebuild" ]; then
git clone . .privatebuild
fi
cd .privatebuild
git clean -df
git pull
if [ -e "pom.xml" ]; then
mvn clean install
if [ $? -eq 0 ]; then
echo "Publishing to: $REMOTE_REPO"
git push $REMOTE_REPO master
else
echo "Unable to build"
exit $?
fi
fi

Dmitry Tashkinov , que tiene una pregunta interesante sobre DVCS y CI , pregunta:

No entiendo cómo "acabamos de crear un CI sin servidor" con el estado de Martin Fowler:
"Una vez que he hecho mi propia compilación de una copia de trabajo correctamente sincronizada, puedo finalmente comprometer mis cambios en la línea principal, que luego actualiza el repositorio. Sin embargo, mi compromiso no termina mi trabajo. En este punto construimos de nuevo, pero esto tiempo en una máquina de integración basada en el código de la línea principal. Solo cuando esta compilación tiene éxito podemos decir que mis cambios están terminados. Siempre hay una posibilidad de que me haya perdido algo en mi máquina y el repositorio no se actualizó correctamente ".
¿Lo ignoras o doblas?

@Dmitry: no ignoro ni doblo el proceso descrito por Martin Fowler en su entrada ContinuousIntegration .
Pero debe tener en cuenta que DVCS agrega publicación como una dimensión ortogonal a la bifurcación .
El CI sin servidor descrito por David es solo una implementación del proceso general de IC detallado por Martin: en lugar de tener un servidor de CI, empuja a una copia local donde se ejecuta un CI local, luego inserta un código "válido" en un repositorio central.

@VonC, pero la idea era ejecutar CI NO localmente, particularmente para no perder algo en transición entre las máquinas.
Cuando utiliza el denominado CI local, puede pasar todas las pruebas solo porque es local, pero luego se descompone en otra máquina.
Entonces, ¿es integeración? No estoy criticando aquí en absoluto, la pregunta es difícil para mí y estoy tratando de entender.

@Dmitry: "Entonces, ¿es integeración"?
Es un nivel de integración, que puede ayudar a deshacerse de todas las comprobaciones básicas (como el problema de formato, el estilo del código, la detección de análisis estático básico, ...)
Como tiene ese mecanismo de publicación, puede encadenar ese tipo de CI a otro servidor de CI si lo desea. Ese servidor, a su vez, puede impulsar automáticamente (si esto todavía es rápido) al repositorio "central".

David Gageot no necesitaba ese nivel adicional, ya estaba en el objetivo en términos de arquitectura de implementación (PC-> PC) y solo necesitaba ese tipo básico de nivel de CI.
Eso no le impide configurar un servidor de integración de sistema más completo para realizar pruebas más completas.