una trabajo tortoise tag subir repositorio proyecto descargar crear copia con como clonar archivos svn shared

svn - trabajo - Subversion y archivos compartidos en repositorios/proyectos?



tag svn (8)

Tener un repositorio para los dos proyectos que comparten. Esto me deja el problema de tener que crear un proyecto / repositorio de nivel superior que contenga los dos y es un problema para el etiquetado. Realmente no quiero etiquetar el pseudo proyecto superior. (las etiquetas, el tronco y las ramas no están exactamente donde yo quisiera).

Al igual que otros, seguramente lo haría de la última manera. ¿Qué sientes que está mal con tener ''solo'' un repositorio? El repositorio trata sobre los derechos de administrador. Aparte de eso, me gustaría ver que un único repositorio tenga un N número de proyectos.

Estoy migrando el repositorio SourceSafe de un cliente (3 proyectos) a SVN y dos de los proyectos comparten archivos fuente. (Estos proyectos son productos separados, con diferentes nombres y versiones de lanzamiento, etc.)

¿Ha resuelto SVN esta deficiencia? ¿Cómo manejan las personas este escenario?

De las opciones que conozco / puedo pensar

  • Use el externo o externo o lo que sea para SVN. He oído que esta no es una buena opción por varios motivos

  • Cree un nuevo proyecto (quizás llamado compartido) que contenga la fuente. El problema con esto es que aún tenemos que obtener ese código (no es una biblioteca) e importarlo al proyecto de alguna manera. Se puede demostrar que es el mismo problema que el anterior e introduce la sobrecarga de un producto / proyecto adicional.

  • Simplemente revise los archivos en ambos repositorios y actualícelos. Esto requiere que los desarrolladores sepan sobre el intercambio y que recuerden registrarse. Supongo que podría escribir un script que verifique todos los archivos compartidos conocidos y los actualice cuando sea necesario.

  • Tener un repositorio para los dos proyectos que comparten. Esto me deja el problema de tener que crear un proyecto / repositorio de nivel superior que contenga los dos y es un problema para el etiquetado. Realmente no quiero etiquetar el pseudo proyecto superior. (las etiquetas, el tronco y las ramas no están exactamente donde yo quisiera).

Probablemente vaya con la última opción.

¿Algún otro comentario?

En mi experiencia, es problemático tener dos proyectos independientes que hagan referencia a los mismos archivos fuente porque puedo agregar o cambiar código en el archivo compartido para satisfacer las necesidades de un proyecto solo para romper la otra versión.

Parece que el truco aquí es permitir que cada proyecto avance de forma independiente, así que como quiera que configure sus repositorios, quiere estabilizar el código compartido de modo que solo cambie cuando lo desee.

Por ejemplo, si el código compartido vive en dos ramas / carpetas del mismo repositorio o si se marca por separado en dos repositorios distintos, o si vive en un tercer repositorio por sí solo, desea el paso de actualizar ese fragmento de código ser uno manual que no tiene efectos secundarios, que puede aislar, eliminar errores y corregir errores.

He descompuesto este código en un tercer repositorio y luego migro periódicamente ese código a mis repositorios de proyectos dependientes como pasos internos de actualización y actualización; Luego, mis proyectos individuales tienen una revisión que se ve como "Actualizado a v4.3.345 de Shared.App.dll", que incluye todos los cambios necesarios para trabajar en contra de esa versión.

Si el código compartido es parte del mismo repositorio que los dos proyectos dependientes, tenga una copia por separado en cada proyecto y use fusiones de repositorio para propagar sus cambios.

La forma más segura de hacerlo es tener un tercer proyecto que construye el origen compartido en una biblioteca que es utilizada por los otros dos. El proyecto de la biblioteca tiene su propio repositorio SVN.

Incluso puede hacer esto con archivos compartidos que son solo encabezados, simplemente déjelos en el directorio del proyecto lib y agréguelo a la lista de includes.

Tener el mismo archivo en dos proyectos, incluso con el control de soruce, ¡tarde o temprano te pide problemas!

No mencionas el lenguaje o la herramienta de compilación que estás utilizando, pero para los proyectos de Java, vale la pena investigar sobre Maven. Una de las características es que se extiende esencialmente para permitirle atraer dependencias externas. Eso alivia una de sus preocupaciones acerca de tener que crear, mantener y etiquetar un metaproyecto. También le permite extraer desde HEAD del proyecto externo, o extraer de una etiqueta determinada, lo que alivia una de las preocupaciones de un póster anterior sobre compartir archivos comunes entre proyectos y causar rupturas inadvertidamente, ya que puede controlar cuándo cada proyecto utiliza una versión más nueva de los archivos compartidos de forma independiente.

No sé exactamente lo que oíste de svn: external, pero creo que eso es lo que deberías usar aquí. Incluso puede especificar que su externo apunte a una rama estable o etiqueta de lanzamiento de su fuente compartida, o incluso señalar dos etiquetas diferentes de los otros dos proyectos que lo utilizan (puede necesitar esto si soluciona algún error en el código compartido lo antes posible) para el proyecto A, pero no tienes tiempo suficiente para probarlo completamente con el proyecto B).

Lo peor que podría hacer es su opción 3 (actualización cruzada de dos versiones de los mismos archivos).

Usa un repositorio, por supuesto. Puede haber más código compartido más adelante.

¿Cuál es exactamente el problema con el etiquetado? Entonces tiene una carpeta adicional en la etiqueta, pero no le cuesta espacio. Si realmente no quieres esa carpeta adicional, aquí tienes una idea para organizar el árbol:

  • /
    • el maletero
      • prj1
      • prj2
      • compartido
    • etiquetas
      • tag1
        • prj1
        • compartido

Es decir, cuando desea etiquetar prj1, crea tag1, luego copia prj1 y lo comparte en él.

Usar un disparador para actualizar los archivos suena como una mala idea. De alguna manera, se desincronizarán. Realmente, la solución con código compartido es extraerlo en una biblioteca y usar esa biblioteca en múltiples soluciones. Sin embargo, eso parece estar fuera del alcance de su proyecto, por lo que la última solución es su mejor opción.