Control de versiones: administración de fonts de componentes comunes

¿Cómo maneja la fuente común de la biblioteca en un DVCS?

Actualmente, mi equipo usa Perforce para administrar nuestros proyectos de software. Utilizando la function "Mapeo del área de trabajo" de Perforce, puedo mapear fácilmente el origen común de la biblioteca en los directorys de la aplicación de desarrollo de una manera que mantenga la transformación entre la gestión de la fuente y el trabajo del proyecto de desarrollo transparente. Por ejemplo, el repository se ve más o less así:


SCM TREE STRUCTURE

  • raíz
    • aplicaciones
      • ForumSite
      • AdminTool
    • común
      • event.logger
      • json.parser
    • db
      • Usuarios
      • Configuración del sitio

Debido a la ingeniosa function de mapeo P4, nuestros desarrolladores pueden get un set completo de fonts para los proyectos en los que trabajan de la forma que tenga más sentido utilizando un map de espacio de trabajo. Una carpeta de proyecto de desarrollo típica podría verse más o less así:


DEV PROJECT FOLDER

/projects /FALL-2009 /ForumSite /deps /event.logger /json.parser /AdminTool /deps /event.logger /json.parser /Users-db /SiteConfiguration-db /FALL-2009-PATCH-01 /json.parser /SiteConfiguration-db /FALL-2009-PATCH-02 /AdminTool /deps /event.logger /json.parser /SiteConfiguration-db 

Cuando un desarrollador edita la fuente en cualquiera de sus componentes o aplicaciones, los cambios se vuelven a asignar al directory de control de la fuente correcto en el punto de versión correcto. Esto es transparente para el desarrollador, networkinguciendo la complejidad de la administración y el time para configurar nuevos proyectos.

Estoy investigando Git, Bazaar y Mercurial como posibles alternativas a Perforce. ¿Alguien puede darnos una idea de cómo se maneja la fuente común de componentes en el mundo de DVCS?

En Git, git submodule para este propósito.

Los submodules de Git se almacenan como references a una revisión de otro repository, junto con un file que proporciona una URL para encontrar el otro repository. Cuando realiza una git submodule update , Git clona una copy del repository al que se hace reference (o puede configurarlo para que apunte a una copy diferente del mismo repository en una URL diferente, ya que es un DVCS y cualquier clon de un repository que contiene la revisión referenceda también funcionará), y luego verifique la revisión referenceda.

Lamentablemente, no es tan transparente como uno podría desear. Comprobar una nueva revisión en el repository principal en realidad no revisa el submodule; necesita hacer una git submodule update explícita git submodule update para lograr esto. Hemos intentado envolver git pull; git submodule update git pull; git submodule update como un solo command, pero hay muchos otros commands (como git rebase ) que implican el control de files que pueden git rebase a un estado confuso porque tampoco actualizan los submodules. Una vez que se familiarice con el funcionamiento de los submodules, todo saldrá bien, pero proporciona un poco de fricción.

Hace dos días se formuló una pregunta muy similar en una forma específica mercurial:

¿Cómo gestiona la gente los cambios en los files de biblioteca comunes almacenados en repositorys mutiples (Mercurial)?

El soporte de Subrepo, ahora bien soportado en Mercurial, parece ser la mejor opción para su configuration.

En Bazar estoy usando el complemento scmproj, que me permite especificar la configuration requerida de los componentes, de modo que puedo proporcionar cualquier map entre las twigs reales y su set en el disco local, como describió.

estamos usando git, y estamos muy contentos con su function de submodule. Te permite integrar otros git-repositorys en el actual, por supuesto, con revisión. ¿Qué puedo ver? Funciona bien 🙂