Organizar mis propias bibliotecas externas en control de revisión

Quiero configurar un repository SVN para "controlar la revisión" de mis proyectos. Actualmente, mi espacio de trabajo se ve así, y tengo la intención de mantenerlo así:

\workspace \myPrj1 \myPrj2 \myLibBase \myLibA \myLibB 

myPrj1 está utilizando myLibBase y myLibA . myPrj2 está utilizando myLibBase y myLibB . Tendré más proyectos próximos, que usarán las bibliotecas. He escrito y estoy escribiendo las bibliotecas yo mismo. Mientras trabajo en cualquiera de los proyectos, constantemente trato de mejorar no solo el proyecto sino también las bibliotecas: encontrar errores, agregar funciones, etc.

¿Ahora cómo organizo esto en un repository?

Esta es mi idea, pero ¿es la mejor solución?

  1. Siempre usaré el espacio de trabajo como raíz del proyecto.
  2. Siempre includeé las bibliotecas que está usando un proyecto en la carpeta del proyecto snv
  3. Siempre tendré proyectos snv adicionales para las bibliotecas

Luego, en el repository, el ejemplo anterior se vería así:

 \repository \myPrj1 \myPrj1 \myLibBase \myLibA \myProj2 \myProj2 \myLibBase \myLibB \myLibBase \myLibBase \myLibA \myLibA \myLibB \myLibB 

Teniéndolo así

… sobre los proyectos:

Cada vez que check-in una copy de trabajo de un proyecto, siempre tengo todas las fonts, incluido el check-in de bibliotecas juntos. Así que cuando reviso una revisión, siempre recibo todas las fonts (incluidas las bibliotecas) tal como estaban en el momento del check-in.

… con respecto a las bibliotecas:

Además, puedo registrar una copy de trabajo de una biblioteca en el proyecto svn de las bibliotecas, cuando pienso que es una versión agradable y estable. Esa versión podría ser revisada cuando creo un nuevo proyecto.

¿Alguien puede confirmar que esta es una buena idea? ¿La mejor práctica? ¿Hay un mejor enfoque? ¿Puedo encontrar documentation / tutoriales / .. sobre este tema? ¿En la networking? ¿En un libro?

Parece que esto es lo que estás buscando: Externos

Extracto: "A veces es útil build una copy de trabajo que esté compuesta de una cantidad de loggings diferentes. Por ejemplo, puede que desee que distintos subdirectorys provengan de diferentes ubicaciones en un repository o tal vez de repositorys diferentes por completo. hasta ese escenario usando svn checkout a mano para crear el tipo de estructura de copy de trabajo anidada que está tratando de lograr. Pero si este layout es importante para todos los que usan su repository, cada otro usuario tendrá que realizar las mismas operaciones de pago que lo hiciste."

Básicamente funciona de la manera que quieras. Está bien, y es necesario, tener múltiples copys de dependencies cuando las necesite en diferentes revisiones por el motivo que sea.

Parece que no tiene sentido tener más de una copy de su biblioteca (digamos myLibBase ) en el repository. El control de versiones está ahí para ayudarlo a editar una sola copy de su código, mientras realiza un seguimiento de todos los cambios. En la forma en que sugiera (si lo entiendo correctamente), tendrá una copy versionada de myLibBase para cada proyecto, lo que significa que si realizó un cambio en la biblioteca de su proyecto, terminará con uno de los 2:

  1. Tienes diferentes versiones de la biblioteca, con el mismo nombre
  2. Tienes que ir y editar todas las copys versionadas para que sean idénticas.

Cualquiera de las posibilidades no tiene sentido para mí.

¿Por qué no tendrías una sola copy versionada de cada biblioteca, y cuando saques un proyecto, también deberás verificar las bibliotecas que este proyecto necesita? Es decir, si desea evitar el check-out de otros proyectos, de lo contrario, podría verificar todo el espacio de trabajo.