Política de control de código fuente

Estoy buscando una visión general sobre las diferentes políticas de control de código fuente. Solo encontré la política de la línea principal y me gustaría conocer mejor a los demás antes de comprometerme con uno con el equipo.Política de control de código fuente

¿Alguien puede proporcionar un enlace a una descripción general o incluso darme algunos nombres de políticas para que pueda iniciar Google en él?

Fuente

2008-09-23 boutta

El documento "streamed lines: branching patterns for parallel software development" es una excelente discusión sobre patrones de ramificación, como el patrón de "línea principal" que menciona; enumera las opciones en forma de patrones junto con la discusión de antipatrones. Uno de los autores es Robert Orenstein de Perforce.

Fuente

2008-09-23 07:20:11 Richard

El enlace está muerto. Creo que este es el correcto: www.hillside.net/plop/plop98/final_submissions/P37.doc – Nippysaurus

Mi política favorita es "No subversión se compromete a que no hacen referencia a las entradas + Auto comentarios Trac para cada confirmación": http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

Fuente

2008-09-23 06:38:49 rjurney

Tal vez, sólo tal vez, en un entorno de mantenimiento realmente bloqueado Prefiero que todos los desarrolladores se animen a registrarse. Obtenga un sistema automatizado de prueba y construcción en su lugar y asegúrese de tener auditorías de configuración para las líneas de base, pero no desaliente las confirmaciones. –

he tenido un gran uso del libro Practical Perforce. Aunque es posible que no trabaje con Perforce, creo que el capítulo 7 (Cómo evoluciona el software) y el capítulo 8 (Administración básica de líneas de código) pueden ser muy útiles. Es posible que pueda rozarlos en Google Books.

Perforce también tiene muchos excelentes artículos sobre el tema. Software Life-Cycle Modeling escribe sobre políticas.
Perforce complete technical documentation.

Y, no, yo tampoco estoy trabajando para Perforce.

Buena suerte, Thomas

Fuente

2008-09-23 06:49:09 homaxto

No cometer mensajes vacíos.

Fuente

2008-09-23 07:06:11

Commit per-change en vez de por archivo.

Esto tiene ventajas siguientes:

Se puede ver más adelante por qué esta única línea se ha cambiado en este archivo exacto (AHA, este fue de corrección de errores para el bug # 123). Si confirma por archivo, los mensajes de confirmación tienden a describir los cambios realizados en el archivo, que de todos modos puede ver con diff. Si comprometes el cambio, entonces los mensajes de compromiso tienden a explicar por qué se realizó el cambio en primer lugar.
Es mucho más fácil revertir o fusionar cambios/correcciones de errores.
Ayuda a organizar mejor su trabajo ya que claramente se centra en un solo error/función/cambio que está trabajando. Usted se compromete cuando termina.

Algunas personas piensan que esta política produce más compromisos pero, según mi experiencia, se obtienen menos compromisos, después de todo. Por ejemplo, está haciendo una refactorización que afecta a 50 archivos. Después de refactorizar, tiene una única confirmación con un mensaje "Subsistema xyz refactorizado".

Para cambios más grandes, debe considerar política dev-branch-per-change.

Fuente

2008-09-23 07:12:50

Esto resulta en una gran cantidad de confirmaciones, ¿o no? ¿Puede nombrar un sistema de control de código fuente que admita este tipo de política? Todos los sistemas que conozco solo admiten confirmación por archivo. – boutta

Sí, es un montón de compromisos. Siempre que sean genuinos (http://thedailywtf.com/Articles/Productivity-20.aspx) eso no es un problema @Vilmantas Baranauskas quiere asegurarse de que pueda rastrear para qué son las promesas individuales. Es un intercambio. –

Subversion lo admite. P.ej. trabajas en el error # 123. Para solucionar este error, debes cambiar 10 archivos. Cuando hayas terminado, en la raíz del árbol fuente que comprometes: svn commit -m "Error fijo # 123". La modificación de 10 archivos se confirma como una confirmación única con un solo mensaje. –

No realice el check-in/confirme ningún cambio que rompa una compilación.

Fuente

2008-09-23 07:44:22 core

Utilizamos varias reglas prácticas como política de compromiso en nuestro proyecto. Estas reglas nos ayudan a mantener cada revisión en estado listo para su implementación. Nuestras reglas son similares a la política de confirmación de KDE, publicada aquí: http://techbase.kde.org/Policies/SVN_Commit_Policy. cada commit debe ser (de mayor a menor prioridad):

con éxito comprobado (compilado, probado, revisado, FxCop'ed, etc.)
Atómica (debe contener sólo un cambio lógico, Fe sola corrección de errores , refactorización, etc.)
no redundante (sin código no utilizado debe añadirse, no comprometen código comentado, eliminarlo, no comprometen accidentalmente los cambios de formato, etc.)
correctamente y completamente comentado
Matched actual fase de desarrollo (por ejemplo, no refactorizar debería e permitido en las ramas de soporte de versión)
Lo más pequeño posible para que coincida con las reglas anteriores.

Desarrollamos una herramienta simple SvnCommitChecker, que nos ayuda a verificar algunas de estas reglas antes de comprometernos con svn. Planeo ponerlo en sourceforge en un futuro próximo con un artículo sobre los beneficios de mantener un buen historial de cambio de svn.

Fuente

2008-09-24 14:10:00 Eugenek

Estos dos son básicamente los mismos:
Version Control for Multiple Agile Teams
Configuration Management Branching Strategy

Estamos utilizando esta estrategia para hacer el tronco estable y permitirá a los desarrolladores hacer lo que necesitan en sus ramas.

Hay algún problema con Subversion, ya que no puede manejar Cyclic merges pero puede trabajar en alrededor de borrar rama de desarrollo después de cada reintegración de nuevo al tronco (irrelevante para otros sistemas de control de versiones)

Fuente

2008-09-24 19:06:42

Política de control de código fuente

Respuesta

Cuestiones relacionadas