Eficientemente muchas versiones de copia de seguridad de un repositorio git con la rama namespacing

Question

En el trabajo, utilizamos Perforce para el control de versiones.Hay problemas con esto:1) con este modelo centralizado, que no puede comprobar los cambios hasta que estén listos para la regresión.Esto significa que nosotros no tenemos control de revisión durante el proceso de desarrollo.2) no Tenemos copia de seguridad de nuestro cliente vista de la estación, así que nuestro trabajo no es seguro hasta que nos puede comprobar en.3) Tenemos problemas de uso compartido de nuestro código a menos que empezar a tener una integración de la rama de configurar.Estoy tratando de configurar un opcional git flujo de trabajo para los desarrolladores que desean utilizar git para vencer a estos problemas.

El plan es usar git-p4 para la interfaz con el servidor de perforce y crear un privado repositorio git.Esta se ocupa de 1).Tengo la intención de utilizar la integración-administrador de flujo de trabajo representado en Git Pro (http://progit.org/book/ch5-1.html) para tener nuestros desarrolladores publicar público repos, teniendo cuidado de 3).

Por último, quiero un lugar donde los desarrolladores pueden empujar a sus cambios de modo que se detuvo en copias de seguridad nocturnas / copias de seguridad externas.La razón por la que no copia de seguridad de nuestro cliente vistas ahora es porque de esa noche de archivo de las copias de seguridad de todo el mundo a la vista del cliente es el espacio ineficiente.Tenemos una gran cantidad de desarrolladores, y que producen una gran cantidad de código.No podemos ser redundante de la copia de seguridad de todo el mundo a la vista del cliente.Sólo queremos preservar la únicos cambios que están haciendo sólo.

Mi pensamiento era tener un desnudo repositorio git, lo llaman omni-backup, que todo el mundo puede poner todas sus ramas (y siéntase libre de sugerir alternativas).Este sería utilizar git uso eficiente del espacio de hash sha-1 y asegurarse de que sólo las versiones únicas de cada archivo de copia de seguridad.El truco es que todos los repositorios de backup tiene que ser parte de la misma repo para obtener el espacio de la eficiencia.

El problema es cuando dos personas completamente diferentes ramas eligió el mismo nombre para su sucursal.E. G.Bob tiene una feature rama y Jane tiene un feature rama, pero son de diferentes características.Si Bob empuja a omni-copia de seguridad, Jane no ser capaz de, como no iba a ser un fastforward de mezcla.

Ahora lo que yo ideal sería que queremos que suceda es que cuando Bob empuja a su rama, la rama se cambiará el nombre de bob-feature en el omni-backup el control remoto.Y cuando él tira de la característica de omni-backup, que vuelva bob-feature.

Esto no parece tan fácil de lograr en git.Parece que puedo usar push ganchos documentado en http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-recibir gancho para volver a escribir el nombre de la ref inmediatamente después de haber escrito y, a continuación, algo se puede hacer para revertir el proceso en el camino de regreso, pero se siente frágil.Alguien tiene una idea mejor?

---

editar:para VonC (Debido a que el código chupa en los comentarios) Su manera suena prometedor, VonC, pero no veo cómo el hecho de que es una captura va a superar a la namespacing problemas.Está usted sugiriendo un cronjob que sabe cómo cambiar el nombre de la rama?

como (muy sucio):

foreach my $user (@users) {
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`);
    foreach my $branch (@branches) {
        system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH"
    }
}

Answer 1

¿Por qué usted necesita para desarrollador para empujar a omni-backup repo?

Para fines de copia de seguridad, me gustaría que en lugar de registrar los diferentes desarrollador del repositorio remoto, y hacer un git fetch cada noche (a partir de la omni-backup server) en todo el remoto repos.
De esa manera, no nombre de la rama de colusión posible.Y un proceso más automatizado (el desarrollador no tiene explícitamente presione cualquier cosa en una operación repo, él/ella no trabaja directamente con el, pero solo se consideraría para copia de seguridad)

Luego me iba a producir un pequeño y agradable git archive de omni-backup y guárdelo.

Answer 2

Si usted puede conseguir a los desarrolladores a seguir ciertas pautas, git push puede hacerlo correctamente.

Si ejecuta este comando:

git push omni-backup feature:bob-feature

donde omni-copia de seguridad es el mando a distancia ref para el repositorio, luego de bob rama de característica empujará a bob-función de omni-copia de seguridad.Pero si confiar que a los desarrolladores no es deseable, cambiar la dirección de flujo y tener omni-copia de seguridad de tirar de los desarrolladores de los repositorios, como VonC sugiere, es la mejor solución