¿Cómo vender la estructura de tronco / twigs / tags de subversión a los usuarios de vss?

Estoy tratando de gestionar los requisitos conflictivos con 2 sets de desarrolladores. Un grupo está haciendo aplicaciones java donde los proyectos tienen múltiples files, otro set funciona en files individuales, por ejemplo, formularios oracle, informes, etc. Ambos sets están actualmente en vss, los java intentaron git, pero los chicos de Oracle / vss lo odiaron: falta de locking principalmente . Así que, como compromiso, intenté svn e implementé el svn: needs-lock para que se ocupara de eso. Pero el siguiente inconveniente fue vender la label / equivalencia de label, por ejemplo, Subversion "label" como SourceSafe

Pero AFAIK no puedo hacer tags sin al less esta estructura:

  • mystandalonefileproject / trunk / mystandalonefile
  • mystandalonefileproject / tags

Para los desarrolladores usar ver su file en un gran directory de formularios de Oracle y luego get, registrar y labelrlo directamente, esto está causando dolor.

¿Alguna sugerencia sobre cómo lidiar con esto? He desarrollado un pequeño script para configurar la estructura anterior para un file arbitrario, y he pensado en crearlo durante la migration de vss a svn.

¿Alguna otra idea? Y desafortunadamente, la subversión y el VSS me dan problemas con la administración.

No es necesario que ejecute SVN con la estructura de tags / twigs / troncales, y si sus usuarios están contentos con el layout antiguo de VSS y sus flujos de trabajo funcionan bien, entonces no hay una razón real para migrar a ningún otro layout.

Puede ejecutar SVN en un estilo cercano a VSS, así que comenzaría haciendo exactamente eso. Active el autopropósito 'needs lock' y déjelos soltar. Luego, una vez que se hayan acostumbrado a Tortoise y las lists de directorys dispersas (conviértanlas en un documento que describe cómo comparar operaciones de VSS comunes con SVN), puede comenzar a sugerir algunas mejoras a su flujo de trabajo, como ramificar su código liberado a una nueva twig , que pones en un directory que simplemente se llama 'tags' … entonces puedes sugerir que algún trabajo se lleve a cabo en un directory separado llamado 'twigs'. Luego, puede contarles sobre la fusión y los beneficios de no tener que trabajar con el código que otra persona ha verificado para detectar cambios menores.

A la gente no le gusta el cambio, eso es justo, así que simplemente preséntelo gradualmente. Cambiar a SVN y cambiar la forma en que funcionan no es bueno. Hacerlo en 2 sencillos pasos es mucho más probable que tenga éxito.