Subversion ¿Fusionar entre múltiples copys de trabajo?

Perdimos por completo nuestro repository y tenemos 8 desarrolladores con cambios sin procesar. Se supone que no se puede restaurar desde la copy de security.

Si una persona pudiera tener acceso a todas las copys de trabajo (ya sea copy de file o compartir de forma remota) ¿es posible fusionar los cambios en nuestras copys de trabajo en una copy de trabajo? La copy de trabajo final se puede importar a un nuevo repository.

En resumen, ¿puede fusionar dos copys de trabajo diferentes sin el server?

editar: por favor no me engañes por no tener copys de security; esa parte está más allá de mi control. Se suponía que estaban recibiendo copys de security todas las noches.

Seguimiento : esto es lo que hicimos:

  1. Comenzó con la copy de trabajo más actualizada de todos los desarrolladores.
  2. Importado eso en el nuevo repository.
  3. Trabajando desde la última revisión de copy de trabajo hasta la más antigua, copymos SOLAMENTE los files con los cambios comprometidos.
  4. lavar-enjuagar-repetir 6 veces. (2 desarrolladores no tuvieron cambios sin connection).
  5. exportó todas las copys de trabajo anteriores, las cerró con cremallera y las almacenó para su custodia si fuera necesario.
  6. Actualizamos nuestras revisiones en la database de administración de versiones para el repo ahora muy joven.

Como perdiste tu repository (lo siento por eso), también perdiste toda la historia.

Todo lo que puedes hacer ahora es comenzar desde cero.

  1. crear un nuevo repository
  2. crea la estructura de la carpeta
  3. exportar la copy de trabajo del primer usuario a una nueva carpeta
  4. importar la carpeta exportada al repository
  5. todos los demás usuarios ahora revisan una nueva copy de trabajo
  6. todos los demás usuarios ahora 'exportan' su copy de trabajo original sobre la nueva copy de trabajo

por 'exportar', me refiero a crear una copy de la copy de trabajo, pero sin las carpetas ocultas .svn en ella.

Hola problema complicado este. Pero esto es lo que haría.

  1. Crea un nuevo repository.
  2. Crea 8 twigs y 1 tronco
  3. Importe que los desarrolladores trabajen en las twigs.
    • Desarrollador 1 en la twig 1
    • Desarrollador 2 en la twig 2
    • etcétera etcétera
  4. Luego comience a fusionarse de la twig 1 al tronco. Y cuando tienes una condición estable en el maletero, continúas con la twig 2, etc.

Y cuando haya terminado con este horrible trabajo, enseñe a los desarrolladores sobre el logging temprano y con frecuencia … Y cómo usar las twigs …

/ Johan

Su problema no es que haya perdido el server, sino el repository en sí. Además de volver a crear un repository nuevo y orderar cuidadosamente las diversas copys de trabajo para importar, no veo qué podrías hacer. Buena suerte.

PD: es malo que no tengas copys de security …

PPS: este es el tipo de problema que DVCS resuelve de forma natural teniendo para la mayoría de ellos una copy completa del repository en el entorno limitado de cada desarrollador.

La manera más fácil sería crear su propio server, crear un repository de testing, agregar una compilation (más estable) y fusionar las copys de trabajo de a una por vez. Pero sí, perdiste toda la historia porque perdiste tu viejo repository.

A continuación, puede crear su repository principal a partir de ese examen.

Intentaría simplemente elegir una copy de trabajo para hacer una import para el nuevo repository, y luego volver a marcar las 7 copys de trabajo restantes en ese repository nuevo usando el conmutador svn, posiblemente con relocation, para hacerles creer que es el mismo repository pero reubicado. Solo intente elegir una copy de trabajo para la import inicial que no tenga (o la menor cantidad posible) cambios estructurales desde el repository perdido: por ejemplo, solo ediciones de files.

Por supuesto, haga toneladas de copys de security de sus copys de trabajo en caso de que lo anterior no funcione 🙂

Subversion conserva la versión original de un file en la copy de trabajo local. Cree un nuevo repository, haga una copy de la copy de trabajo más antigua, invierta los cambios en la COPIA de la copy de trabajo y luego importe esa copy de trabajo a su nuevo repository.

svn import: http://svnbook.networking-bean.com/en/1.0/re12.html

Una vez que haya importado, puede usar svn switch –relocate para volver a marcar las otras copys de trabajo en su nuevo repository, y confirmar los cambios.

svn switch –relocate: http://svnbook.networking-bean.com/en/1.1/ch04s05.html

Cree un nuevo repository en la misma location que el anterior de la copy de trabajo más original (de ese modo, puede capturar más historial en el nuevo repository).

Si y donde no funciona, ingrese .svn-directories desde la salida del nuevo repository. (Por ejemplo, pago y envío, y eliminar todo less los directorys .svn)