Transición de una herramienta de control de origen a otra. Consejo por favor?

Recientemente me dijeron que tengo que migrar nuestro repository de Perforce a TrueChange (McCabe TrueChange) . No había oído hablar de TrueChange hasta ese momento. He utilizado cvs, subversion, vss y forzado hasta el momento. Estoy tratando de encontrar palabras de sabiduría para hacer esa transición y qué esperar de TrueChange. Me encantó trabajar con Perforce y la transición a ella me pareció bastante simple.

¿Me puede ayudar? Estoy usando VS2005, RAD y CruiseControl.

He estado usando TRUEchange desde septiembre de 1999 y creo que eres afortunado de que te hayan dicho que tienes que migrar de Perforce a TRUEchange.

He trabajado con varios sistemas de software CM de código abierto, de producción propia y comercial, y de lejos, TRUEchange es el mejor producto que he usado.

Cuatro cosas que hacen que TRUEchange sea tan bueno (hay más de cuatro, estas son cuatro keys):

  1. Cambiar set basado en lugar de file basado en diferencias . Si 50 files se desprotegen como un grupo, se modifican y luego se vuelven a registrar, los cambios en esos 50 files son una sola unidad denominada set de cambios. TRUEchange maneja líneas base paralelas concurrentes mejor que cualquier otro software CM que haya usado alguna vez. Los Csets se pueden migrar a una línea base numerada más baja o migrar a una línea base numerada más alta. Los conflictos de migration / fusión son raros y hay una herramienta integrada de combinación de 3 vías en los clientes que permite al usuario manejar los conflictos con extrema facilidad. Los sets de cambios se pueden eliminar de una versión particular (en cualquier order) y se pueden volver a agregar. Si se han producido 5 cambios en un file en 5 sets de cambios diferentes, se puede eliminar el 2º cambio dejando los cambios 1, 3, 4 y 5 intactos. También mantiene metadatos completos para admitir el movimiento de files de un directory a otro, cambiar el nombre de los files o cambiar el nombre de los directorys. Los files se pueden eliminar y hay un set de cambios que elimina el file. Como el set de cambios que elimina el file mantiene la id. De file del file, el nombre del file y el directory principal, los files se pueden restaurar en cualquier momento sin tener que volver a cargarlos en el sistema. El historial de cambios se restaura cuando se restaura el file.

  2. Versión de proyecto basada en lugar de la versión de file . Cuando una versión está marcada (similar al labeldo), el contenido de todos los files del proyecto completo se registra como una unidad. En lugar de tener que realizar un seguimiento de los numbers de versión individuales para 5000 files, solo tendría que hacer un seguimiento de los puntos de control para los proyectos que contienen esos files. Mantener el historial de lo que se ha creado para el control de calidad o la implementación es "absolutamente simple", ya que no es necesario rastrear las versiones de los files. TRUEchange usa configuraciones de compilation para agrupar proyectos relacionados y las routes de files donde se extrajeron los files para el process de compilation, en filesystems Unix / Linux, Windows o VMS. Usamos un número de versión de tres segmentos como 2.1.0. La primera compilation (o iteración) para una versión sería 2.1.0.1. El segundo sería 2.1.0.2 y así sucesivamente. Cuando ejecutamos una compilation y finaliza, tomamos los detalles de la configuration de compilation e insertamos los datos en dos tablas de database. Una tabla contiene la información de nivel de configuration de compilation como nombre de configuration de compilation, número de versión principal, número de versión secundaria, número de subversión, iteración, título descriptivo, tipo de compilation (QA o producción) y date y hora completadas. La otra tabla contiene una key externa que apunta a la fila de nivel de configuration de compilation en la primera tabla y contiene el nombre del proyecto, el número de versión principal, el número de versión secundaria, el número de subversión y la iteración del punto de control utilizado para ejecutar la compilation. Con la información de nivel de configuration de compilation y la información de nivel de proyecto, podemos consultar la database e inmediatamente conocer el contenido exacto de cualquier ejecución de compilation. Actualmente tenemos un historial de construcciones desde septiembre de 2001: casi 33,500 construcciones y más de 228,000 loggings de niños. En cuestión de uno o dos minutos pude recrear la estructura del directory de origen para cualquier compilation ejecutada en los últimos 8 años y sé que es absolutamente precisa e idéntica a la ejecución de compilation originalmente. Si tuviera que hacer eso con un sistema de CM basado en la versión de file, se necesitaría mucho time para recrear cualquier compilation dada.

  3. Comandos de línea de command, GUI de Windows, cliente de GUI de Java (StreamCM), personalización y confiabilidad . TRUEchange tiene una multitud de commands de línea de command que permiten un alto nivel de automation. Usando scripts de shell y PHP, hemos podido desarrollar ciclos de compilation totalmente automatizados e interfaces web personalizadas para que los desarrolladores interactúen con el sistema de CM. Las comstackciones de desarrollo se ejecutan cuando el usuario de gestión de configuration con la recuperación de files de TRUEchange se ejecuta desde una página web. Esto garantiza que el código ingresado por los ingenieros se comstackrá cuando sea ejecutado por CM. StreamCM se ejecuta en una variedad de plataforms: Unix (Solaris, AIX, HP-UX, Irix, etc.), Linux (Red Hat, Fedora, Gentoo, etc.), Windows (XP, Vista) y en MacOS (PPC e Intel) ) Esta interfaz unificada permite a los desarrolladores utilizar múltiples plataforms y hacer que el cliente actúe de la misma forma independientemente del sistema operativo. TRUEchange puede ser altamente personalizado utilizando su lenguaje de scripting. Hemos personalizado TRUEchange para que interactúe con nuestra database de CM que se ejecuta en PostgreSQL para que las aplicaciones basadas en web puedan leer metadatos de una database en lugar de consultar el sistema de CM. También hemos personalizado TRUEchange para interactuar con nuestro sistema de seguimiento de problemas en Mercury Interactive Test Director a través de una connection a la database de Oracle. Es altamente confiable. En casi 10 años, tuvimos un error en un repository que requería volver a una copy de security debido a un error de disco. Y como TRUEchange mantiene las transactions que se publican en cada repository, pudimos reproducir las transactions que modificaron el repository en el order exacto en que se aplicaron originalmente. Era un repository poco utilizado, pero solo llevó 10 minutos reproducir todas las transactions de un período de tres días. Tenemos más de 200 licencias de usuario y nunca hemos tenido más de dos ingenieros de CM para apoyar a la base de usuarios. En 2008, el otro ingeniero de CM y yo realizamos más de 6300 versiones de QA y creamos más de 1800 imágenes de implementación para la implementación de producción. Comparado con cualquier otro sistema CM que haya usado alguna vez, TRUEchange requiere mucha less administración, por un gran margen. El otro plus es la disposition de McCabe para mejorar el producto en function de las necesidades de sus clientes. Hemos solicitado numerosas mejoras a lo largo de los años y han cumplido con casi todas las requestes y han superado nuestras expectativas. La otra gran ventaja de TRUEchange es que está diseñado para ejecutarse en un entorno distribuido. Un administrador de licencias controla el acceso al sistema y rastrea en qué serveres se están ejecutando los repositorys. Tenemos un server de licencias y cuatro serveres Linux que ejecutan 97 repositorys. Si necesitábamos agregar serveres para albergar repositorys adicionales, simplemente sería una cuestión de elevar esos serveres, crear los repositorys (o mover los existentes al nuevo server), recreando las secuencias de commands de inicio y detención (a través de un process automatizado) y iniciar los repositorys en el nuevo server. No se requiere intervención del cliente. Y administramos casi 52 millones de líneas de código fuente más files binarys (como files gif, files jpeg, etc.).

  4. Plugin de CruiseControl . Con la última versión del software, McCabe desarrolló un complemento CruiseControl que permite la integración de TRUEchange. No hemos utilizado CruiseControl en este momento porque nuestro software es extremadamente complejo con muchas interdependencies. Esto no es una deficiencia de TRUEchange, sino más bien una falla en CruiseControl. Parece ser el más adecuado para sistemas independientes que no dependen en gran medida de otros sistemas.

Para migrar fácilmente de otro producto CM a TRUEchange, simplemente se trata de captar el concepto de orientado a proyecto versus orientado a files y luego configurar los repositorys para cumplir con los requisitos de security (quién puede acceder a qué y en qué nivel) y la organización de proyectos lógicos del sistemas de software. Si los repositorys y proyectos están configurados correctamente, es simplemente una cuestión de extraer los files del antiguo sistema CM y cargarlos a granel en los proyectos TRUEchange.