Implementación de SVN "branch", "tag" y "trunk" con compositor y file de configuration

He leído mucho Q / A aquí sobre el significado de los directorys "branch", "tag" y "trunk" en los repositorys SVN, y como ahora creo que entendí, estoy tratando de implementarlo.

Utilizo Virtualmin para administrar mi server, y crea repositorys para mí a través de su GUI web. Sin embargo, una vez creado, mi repository está vacío, así que supongo que necesito crear la estructura del directory y comprometerlo. Una vez hecho esto, coloque los files de mi proyecto en tronco, y como estoy en un estado de versión estable, debo ramificarlo en branch / xxx (que será un punto de guardado en mi desarrollo), y en tags / xxx (que será mi versión de desarrollo).

Si estoy en lo correcto hasta ahora, entonces cambio con Tortoise a mi nueva label, y eso solo cambiará en mis próximos commits. Por cierto, con Tortoise, ¿tendré que hacer clic con el button derecho en el directory de tags actual, o aún podré confirmar / revertir directamente desde la carpeta raíz de mi proyecto?

Mi proyecto actual tiene un file de configuration que define un par de routes absolutas, tal vez está mal pero no he encontrado la forma de evitarlo. Como quiero poder ver mi proyecto ejecutándose desde cualquiera de esas twigs / troncales, ¿significa eso que necesitaré un file de configuration diferente para cada versión? Si es así, ¿debería agregar este file a la list de ignorar? Me refiero a lo que se consideraría una buena práctica?

Pregunta adicional: si quiero usar Composer en este caso, ¿dónde deberían estar mi composer.json y el directory de proveedores?

¡Gracias!

Estás confundiendo tags y twigs. Las tags no deben ser modificadas. Por lo general, se crean (desde el enlace o desde una sucursal) cada vez que se realiza un lanzamiento de su aplicación.

Las twigs se utilizan para mantener el trabajo en progreso.

Debe verificar el directory troncal a una copy de trabajo. Para cambiar a una twig, use el command de cambio. No hay ninguna razón para tener files de configuration separados para cada twig, ya que su copy de trabajo, en la misma location, puede apuntar a lo que desee: tron ​​troncal, una twig o incluso una label. El punto key es que la raíz de la copy de trabajo debe ser la raíz de su proyecto:

Entonces, suponga que sus files de proyecto contienen los siguientes files:

index.php config.txt some_folder foobar.php 

Su repository tendría el siguiente layout:

 trunk index.php config.txt some_folder foobar.php branches maintenance_1.0 index.php config.txt some_folder foobar.php feature_refactor_index_page index.php config.txt some_folder foobar.php tags v1.0 index.php config.txt some_folder foobar.php 

Y su copy de trabajo sería:

 MyProject --> references trunk index.php config.txt some_folder foobar.php 

Si desea trabajar en la twig de características, cambie a la twig, y ​​su copy de trabajo será entonces

 MyProject --> references feature_refactor_index_page index.php config.txt some_folder foobar.php 

Por lo tanto, sería exactamente lo mismo, y no hay ninguna razón para que el file de configuration contenga diferentes routes de files.