¿Cómo puedo hacer que dos "streams de desarrollo" (twigs?) Se rastreen entre sí y permanezcan diferentes de maneras particulares?

BREVE:

Quiero tener dos (o más) "streams de desarrollo" / entornos que se rastreen entre sí, enviando cambios entre ellos en ambas direcciones, sin converger totalmente, mientras se conservan ciertas diferencias keys, esenciales.

DETALLE, UN EJEMPLO EN PARTICULAR:

Aquí hay un ejemplo particular:

He estado controlando la versión de mi directory personal, glew-home, por, oh, 28 años. RCS, SCCS, muchos envoltorios de RCS, CVS, SVN, un breve período de experimentación con los primeros DVCS como Monotone y Darcs, bzr, git y ahora Mercurial. Por el momento, estoy contento con Mercurial, aunque volveré a git o bzr según sea necesario.

Ahora, mi directory de inicio es similar, pero no idéntico, en muchos sistemas. Las mayores diferencias se encuentran entre Cygwin y los diversos Linux en acción. Intento que sean lo más simples posible, pero las diferencias surgen y, a menudo, deben persistir.

Aquí hay un ejemplo trivial de las diferencias: en Cygwin, en mi computadora personal, ~ / LOG es un enlace simbólico a ~ / LOG.dir / LOG.cygwin.glew-home, mientras estaba en el trabajo ~ / LOG es un enlace simbólico a algo como ~ / work / LOG.dir / LOG.work.

Motivo: cualquier cosa propietaria necesita permanecer en el trabajo. ~ / work es un repository separado, ~ / work / .hg, y NO se empuja / tira ni se sincroniza con mi computadora personal.

Problema: quiero mantener estos enlaces simbólicos (y varios otros files) diferentes. Pero quiero sincronizar todos los demás files. Hago cambios en mi entorno en ambos lugares. Si realizo un cambio en mis ~ / .emacs en el trabajo, quiero enviarlo a casa, y viceversa.

P: ¿cómo puedo hacer esto más cómodamente?

En los viejos times, usaría un repository común, digamos un repository común de CVS. CVS no maneja enlaces simbólicos, pero dice que tenía un script que generaba enlaces simbólicos desde una plantilla almacenada en CVS. Me encargaría de que la plantilla de enlace simbólico para ~ / LOG tenga diferentes twigs para mi cygwin-laptop y para el trabajo. Crearía espacios de trabajo con la mayoría de los files apuntando a la misma twig de sus correspondientes repositorys RCS / CVS, mientras que los files que difieren entre cygwin-linux y work verían sus twigs correspondientes en sus espacios de trabajo correspondientes.

Esto funcionó, aunque fue un poco difícil de mantener.

No he descubierto una buena manera de hacer esto con un DVCS moderno, como Mercurial (o Got, o Bzr).

Estas herramientas DVCS modernas hacen ramificaciones de repositorys integers, no ramificaciones por file. No entienden la noción de dos twigs que son idénticas para la mayoría de los files, pero que difieren solo en ciertos files.

Cuando bash rastrear dos twigs, siempre termino con las diferencias esenciales que se propagan.

Algunos han sugerido Makefiles. No atractivo.

Consideré hacer los cambios esenciales en las revoluciones básicas y cambiar constantemente. Pero no me gusta volver a basar tanto.

Mejores ideas apreciadas.

¿Ednetworkingón?

En git puedes mantener una twig master con todos los files comunes (tal vez más los diferentes en algún estado pnetworkingeterminado) y twigs personalizadas como work o cygwin .

Cuando desee realizar un cambio que se propague a cada máquina, hágalo en el master . Si desea que algo vaya solo a las máquinas de trabajo / cygwin, hágalo en una sucursal apropiada.

Cuando extrae nuevos cambios de la máquina master en una máquina que tiene una twig personalizada desprotegida, simplemente tiene que git rebase master de git merge master o git merge master git rebase master desde esa twig.

Cuál debería usar es una cuestión de preference, el directory de trabajo resultante es el mismo, solo el historial es diferente. Con la merge , siempre verá cuando actualizó la twig personalizada con cambios desde el master . Al usar rebase , parecerá que todas las personalizaciones se ramifican desde la punta del maestro, como si primero hubieras hecho todo en el maestro y solo luego hubiera personalizado las personalizaciones.

Lamentablemente, no tengo idea acerca de otros DVCS ya que no tengo ninguna experiencia con ellos, sin embargo, creo que este procedimiento para git es bastante sencillo.