tokyo starter new esd embarcadero edition community delphi version-control project-structure

starter - embarcadero delphi free



¿Cómo gestiona sus proyectos Delphi con componentes de terceros en Version Control? (5)

Con Subversion, uso la función Externals. Facilita el uso de elementos de terceros en proyectos múltiples; cuando revisa un proyecto, también obtiene las dependencias externas.

Si aún no lo tiene, debería obtener una copia de Pragmatic Version Control Using Subversion. Es un gran libro sobre la funcionalidad de Subversion y cómo hacer cosas. Mientras hace referencia a SVN desde la línea de comandos, la información también se puede traducir fácilmente a la GUI en TortoiseSVN.

Para reinstalar los componentes en Delphi para proyectos anteriores, generalmente exporto las entradas de registro para cualquier versión de Delphi utilizada en la carpeta del proyecto y luego verifico ese archivo .REG en Subversion junto con el proyecto. Puede verificar fácilmente el proyecto, exportar su sección de registro existente de Delphi para la versión correspondiente de Delphi, importar el archivo .REG de su carpeta de origen del proyecto y luego iniciar Delphi con todos los componentes instalados.

En cuanto al problema del "binario BPL", ¡qué vergüenza! Si tiene proyectos que dependen de herramientas de terceros, debe comprar la fuente para ellos. De esta forma, estará protegido contra la quiebra de esa empresa, o retirando el soporte para los componentes, o las nuevas versiones de Delphi que no son compatibles. Siempre obtengo la fuente de componentes de terceros; si la fuente no está disponible, busco un producto diferente o escribo el código yo mismo. Se llama autopreservación. :-)

La instalación de componentes de terceros siempre lleva mucho tiempo, especialmente si tiene grandes, pero también requiere más tiempo si configura el entorno en más de una computadora.

Y estoy pensando en agregarlos al Control de versiones (Subversion), por lo que siempre será fácil verificar el proyecto con todos sus componentes necesarios.

Entonces, ¿cómo lo gestionas y cuál es la mejor práctica para administrarlos dentro del VCS?

También considere que algunos de estos terceros provienen sin fuente, pero como bibliotecas Delphi. (BPL).


En primer lugar, estoy de acuerdo con Ken y Fabricio en que debe tener el código fuente de todos los componentes que está utilizando en un proyecto. Cualquier otra cosa es solo pedir problemas.

No utilizamos Subversion para nuestro control de código fuente, pero supongo que lo que hacemos todavía sería aplicable ...

Cada proyecto en el que trabajamos tiene una copia completa de todos los componentes (fuente) utilizados en ese proyecto. Cuando lanzamos, creamos una rama de versión que incluye los componentes y el origen del proyecto. Cada proyecto incluye su propio directorio BPL.

Siempre creamos accesos directos por separado para ejecutar Delphi para cada proyecto (o rama de un proyecto) en el que queremos trabajar, y usamos el parámetro de línea de comandos -R para establecer una clave de registro única para la configuración de Delphi para ese proyecto.

Luego nos aseguramos de anular la variable de entorno de ruta dentro de Delphi para apuntar a nuestro directorio BPL de proyecto en lugar del directorio Delphi BPL normal.

Configuramos los directorios de salida BPL y DCP para todos los componentes para que sean el directorio local del proyecto BPL.

Esto nos permite tener múltiples versiones de Delphi, con múltiples versiones de proyectos usando diferentes versiones de componentes sin ningún problema.


Estoy de acuerdo con Ken White en esto: delphi componentes de terceros utilizados en el código de producción

debe tener el código fuente

Período. Las distribuciones compiladas de solo binarios son solo para fines de evaluación. Es nuestra política aquí.

En cuanto a la pregunta: en realidad no los pongo en VCS. En realidad, uso la última versión que mis proyectos compilan y funcionan. El lío con el sistema, la búsqueda, la biblioteca, etcétera ... las rutas no valen la pena. 2 JVCL en la misma máquina o versiones de ida y vuelta de cualquier nuevo proyecto? ARRRRGH.

Si tengo que usar una versión anterior en un sistema de mantenimiento, coloque una nueva VM e instale la última versión. ¿Funciona? De acuerdo. ¿No? Permanece en la máquina virtual hasta que descubro una forma de integración en el entorno principal.

Una versión de cada cosa es más que suficiente.


Si tenemos la fuente, la incluimos en nuestro repositorio, en una carpeta separada.

Si no tenemos la fuente, entonces mantenemos los binarios más recientes (bpl, dll, lo que sea) en el repositorio, e incluimos las instrucciones de instalación / uso en un documento de configuración.

Se parece a esto:

/root /third_party_stuff /vendor1 --we *do* have the source for this /src /bin /vendor2 --we *do* have the source for this /src /bin /vendor3 --we don''t have the source for this one /bin /our_stuff /project1 /src /bin /project2 /src /bin


Vale la pena mencionar que algunas empresas como LMD ofrecen acceso remoto a su propio repositorio SVN para clientes con suscripción de soporte. Creo que es una buena manera de obtener correcciones de errores rápidas para problemas críticos.