¿Cómo manejar nuevas versiones de una aplicación .NET en Subversion?

Soy nuevo en el control de fuente en general y me pregunto cómo manejar el siguiente escenario:

Digamos que tengo una aplicación escrita para una plataforma, digamos Windows Forms en .NET y la he desarrollado usando Subversion (o cualquier software de SCM , supongo).

Ahora me gustaría actualizar la aplicación para usar WPF y tal vez agregar algunas otras mejoras. ¿Continuaría el desarrollo en una twig del tree para esta versión 2.0 de WPF?

Tal vez haya algunos files que seguirán siendo los mismos que contienen lógica de negocios, acceso a datos, etc. pero realmente querría comenzar una solución completamente nueva y tal vez pedir prestada algunas cosas aquí y allá de la versión 1.0.

¿Cuál es la mejor práctica? Cree una nueva carpeta de aplicación con sus propias carpetas de tree / twig / label o intente mantener la nueva versión como parte de la carpeta de la aplicación original 1.0.

¿Cómo vas sobre esto?

¿O en un caso less drástico como actualizar una aplicación de Silverlight 2 a Silverlight 3? ¿Entonces que?

Agradecería cualquier orientación de aquellos que han pasado por esto antes.

En general, hay un par de escuelas de pensamiento con respecto al control de versiones, pero la que he encontrado más a menudo que tiene sentido para mí es:

  • Hace todo el desarrollo que impulsa el proyecto hacia adelante en la twig principal, también conocido como HEAD en CVS y 'trunk' en subversión. Éste recibe todos los cambios como los que describes, incluido el cambio de bibliotecas de GUI, la actualización de herramientas de terceros y todo eso. La punta de esa twig siempre debe reflejar la última y esperable versión más grande del software, pero nunca verá la luz como un lanzamiento.
  • Para cada lanzamiento, creas una twig de lanzamiento. Todo el trabajo relacionado con el lanzamiento y solo con el lanzamiento se realiza en esta twig específica. Estos deberían ser principalmente correcciones de errores. Los cambios que pueda realizar en esta twig pueden fusionarse nuevamente en la twig principal, pero no esperaría muchos, si hay cambios, desde la twig principal hasta la twig de publicación. La twig principal es un objective mobile, mientras que la versión no lo es.

Estructurar mis proyectos de esta manera:

/branches (different working sets) /tags (revisions, etc) /trunk (current production state) /lib (3rd party libraries and dependencies) /tools (build tools) /src /component-a /component-b /component-c 

Debido a que la subversión solo rastrea los deltas para cada confirmación, no hay una penalización en el lado del server por la bifurcación de todo en el enlace troncal. La única consideración es cuánto espacio de disco en su máquina local desea usar.

Cuando deployment el código, "lo etiquete" debajo de las tags. Cuando necesite derivar el código experimental, cree una twig.

EDITAR: en términos de desafíos asociados al intercambio de bibliotecas entre diferentes sistemas operativos o entornos de time de ejecución, realmente depende de qué tan grande sea el proyecto y los componentes. En algunos casos, tiene sentido dividir la lógica "central" en su propio proyecto, y exportar una biblioteca comstackda "versionada" a su (potencialmente) muchos consumidores. Este enfoque solo funciona bien si la lógica central es estable y no tiene una versión frecuente.

De su comentario en @Timo Geusch parece que su pregunta es sobre algo más que manejar versiones del software lanzado, que se trata más de elegir un número arbitrario. Reorganizar su código tiene poco que ver con el control de versiones y más acerca de cómo ha configurado su solución .NET (es decir, la architecture del código). Tomemos el siguiente ejemplo, bastante mal llamado:

 MySolution /MyWinFormsProject 

En este ejemplo, tenemos una solución llamada MySolution . Es un proyecto, que es un WinForms llamado MyWinFormsProject . Cuando queremos pasar de tener un proyecto de WinForms a uno de WPF, será problemático porque la mayor parte del código que tenía en esa aplicación de Winforms tendrá que ser reescrito. Y si tienes más de 10000 líneas de código, esta será una tarea desgarradora.

Si se encuentra en esta situación, debería comenzar a refactor arrancando el código común y colocarlo en otro proyecto (preferiblemente uno de Class Library ) que podríamos llamar MyCommonCode . Recuerde que necesita hacer reference a MyCommonCode en MyWinFormsProject .

 MySolution /MyWinFormsProject /MyCommonCode 

Comprométase cuando hayas terminado, el número de revisión boostá. Puede volver a esto en caso de que lo haya jodido más tarde. Luego crea el nuevo proyecto, un WPF llamado MyWPFProject . Solo necesita establecer MyWPFProject como proyecto de inicio si desea comenzar desde ese lugar.

 MySolution /MyWinFormsProject /MyCommonCode /MyWPFProject 

Cuando hayas hecho eso, vuelve a cometer. No es necesario eliminar el proyecto WinForms hasta que haya terminado con uno de WPF.

Nota: La forma de dividir y nombrar exactamente sus proyectos y espacios de nombres depende de usted, aunque mirar algunos proyectos de fonts abiertas le ayudará a inspirarse.

Usted label lo que está actualmente en el encabezado del repository como "versión 1.0" / etc.