Cambios en el código de fusión sin control de fuente verdadero

Tenemos algunos desarrolladores trabajando en la misma solución VS2005, pero nuestro control de fuente es muy malo. (Nuestra empresa utiliza Harvest, a la que damos un voto de desconfianza).

En este momento, todos solo estamos trabajando con los files en una unidad de LAN compartida. Obviamente, esto causa algunos problemas. Pero creemos que es mejor que trabajar localmente y rastrear los files que tocamos en una spreadsheet y fusionar todo de forma manual. ¿Alguien tiene una estrategia para fusionar nuestros cambios?

Algunos de los problemas existen debido a la beaurocracia corporativa (como exigir Harvest). Esas mismas políticas impiden la introducción de nuevas herramientas en nuestro entorno. Entonces, las estrategias que eviten comprar / download nuevo software funcionarían mejor para nosotros.

Trate el recurso compartido como si fuera su sistema de control de origen. Haga que el recurso compartido sea de solo lectura, lo que obligará a los desarrolladores a get copys locales para realizar cambios. Luego tienes una versión algo estable para comparar. Esto ayudaría a facilitar el poder hacer "fusiones". El código de "Comprobación" debería consistir en algún tipo de estrategia de respaldo para el file (posiblemente haciendo una copy del file con una timestamp y nombre de usuario como parte del nuevo nombre de file) y replace el original con la nueva versión.

Dicho esto, realizar este tipo de actividad sin un sistema de control de fuente real que sea confiable va a ser difícil y propenso a errores.

Aprende a usar Harvest. Se necesita un poco de esfuerzo para que las cosas funcionen sin problemas, pero en general es un excelente sistema de control de fuente.

Otra posibilidad sería Beyond Compare from Scooter . Tiene fusión de dos y tres vías y gran funcionalidad de diferencia en files y directorys. Si quieres saber un poco más al respecto, escucha el podcast delphi de Jim McKeith .

Pero como la mayoría de los demás recomendaría usar Git o aprender Harvest. Si el sistema de control de fuente permite cambiar su aplicación de diferencias, Beyond Compare sería un excelente reemploop.

Obtenga git e instálelo localmente en la máquina de cada desarrollador. Luego configure los repositorys para replicar.

Probablemente tengas que download algo a less que quieras hacerlo a mano. Recomiendo encarecidamente a Winmerge . Es gratis, de código abierto, y probablemente sea mejor para ti una pequeña descarga que no estropee las cosas.

Hay una herramienta de command-line estándar de Unix llamada fusión que fusionará bastante inteligentemente dos sets de cambios en un file. La syntax es:

merge mine older yours 

Donde "mío" es el file con sus cambios, "más antiguo" es el file original y "suyo" contiene los cambios de otra persona.

Sin embargo, no estoy seguro de si tiene una caja UNIX (o Mac OS X) para hacer esto.

Hay dos problemas distintos: control de versiones y fusión. No hay excusa para NO usar un sistema de control de versiones. Si la empresa ha decidido una solución (por el motivo que sea), úsala. No me gusta o no "tener confianza" en ello no es una razón válida para no usarlo. Y usar una unidad compartida para imitar un sistema de control de código fuente está más allá de lo loco.

La fusión es un segundo problema. Simplemente necesita una herramienta diff / merge. Elegir uno. ¿Cómo has ido tanto sin uno?

Araxis es genial. Cuesta unos pocos dólares. La gente de SourceGear ha estado distribuyendo libremente su herramienta diff / merge por algún time (la que viene con Vault). También es un contendiente sólido. Esos son dos que he usado y sé que todavía están en el mercado. Hay otros que ya han mencionado.

Fusionar todo a mano no es una solución sostenible. Combinar eso con no usar un VCS es una receta para el desastre.

Trabajar fuera de una unidad compartida no es una buena idea, y obtiene mi voto de "no confianza".

Sería demasiado fácil sobreescribir los cambios de otros, no tiene seguimiento de cambios, no hay forma de ramificar o labelr / labelr, etc.

Puede que esta no sea una opción viable, pero quizás podrías usar un sistema distribuido como bazar , git o Mercurial .

La razón por la que sugiero esto es que tienen muy poca carga y se pueden usar con otros sistemas. Sé con bazar que el repository es simplemente una carpeta oculta añadida al directory.