Subversion en Eclipse – Rama de conmutación con trabajo no comprometido en repository

Supongamos que tengo el siguiente senario:

Trunk es mi principal línea de desarrollo donde los progtwigdores se comprometen cuando termina. Branch V1.0 es una twig que creé al lanzar la versión 1.0.

El progtwigdor está trabajando en el tronco, pero necesita cambiar a la twig para corregir errores. Cuando regrese al troncal, Subversion me dará la última información en el repository SVN que no incluye los cambios recientes. Entonces, para cambiar, tendrá que comprometer lo que tiene porque de lo contrario los cambios se "perderán". Sé que todavía se guardan en el repository local, pero todavía significaría restaurarlos uno por uno una vez que cambie de location.

¿Me estoy perdiendo de algo?

Editar:

Ahora estoy pensando en estas líneas:

Cada progtwigdor tendría su propia twig de desarrollo "privada" fuera del trunch. Él podría comprometerse allí cada vez que quiera. Cuando haya terminado lo que ha escrito, puede fusionarlo en el baúl. Él comienza de nuevo para la siguiente tarea. Si en algún momento se le pide que corrija un error en alguna otra versión, puede comprometerse con su propia twig privada, search el lanzamiento y arreglarlo. Luego, después de confirmar los cambios en la corrección, puede volver fácilmente a su propia twig de desarrollo.

Funcionaría eso?

Creo que la subversión no está pensada para el cambio como usted lo describió. Una solución sería tener dos espacios de trabajo, uno para la twig y otro para el tronco, para que pueda pasar de uno a otro sin problemas. Sé que no es agradable.

Considere cambiar a una herramienta de control de versiones que sea más adecuada para su enfoque. Mi propia sugerencia es Mercurial , junto con MercurialEclipse . Los únicos inconvenientes que conozco son que Subversion es más adecuada para almacenar files binarys y que los subrepositorys de Mercurial no funcionan tan bien como los externos de Subversion.

En Mercurial, sus progtwigdores podrían enviar sus cambios a sus repositorys privados, fusionarse y comprometerse localmente nuevamente, y luego enviar los cambios resultantes a un repository oficial, desde donde otros progtwigdores los incorporarían a sus repositorys privados.

La mejor solución para tales propósitos es tener dos copys de trabajo separadas. Uno para trabajar con el tronco y otro que trabaja con la twig.