Acceso a units en el servidor
 

Hola a todos, tengo un problema de lentitud en la utilización de Delphi 7. Les comento un poco la situación: Tengo 4 Pc's en red, una es el servidor (Server) , allí se encuentran las units con las clases que utilizamos para desarrollar nuestras aplicaciones. Además, están en el servidor los componentes que utilizamos (RX, JVCL, algunos hechos por nosotros). Las 3 PC's restantes tienen instalado Delphi 7 y como componentes instalados tienen los que residen en Server.
El problema ocurre cuando, dentro del entorno de Delphi, quiero cambiar de una unit a otra o cuando presiono Ctrl + Barra Espaciadora (para que Delphi me complete el código fuente). El problema es la PC que se pone a "pensar", y me fijo en el hub y las luces indican que hay transferencia por la red. Este problema lo hace frecuentemente. No entiendo, en el caso de las teclas, porque accede a Server.
Detalle de las PC's:
- Server: AMD Duron 800 Mhz, 256 MB RAM
- Terminal 1: Intel PIII 750 Mhz, 256 MB RAM
- Terminal 2: AMD Athlon 2400+, 256 MB RAM
- Terminal 3: AMD Athlon 1700+, 256 MB RAM

Espero que alguien me pueda dar una ayuda.
Desde ya muchas gracias.

Guillermo

Hola, no sé si esto te servirá pero deberías revisar la configuración de Delphi.

Comprueba en Tools->Environment->Library-> Library Path
y Browsing Path.

Es impprtante el orden en que están las unidades porque es el que sigue Delphi para buscar opciones, componentes, units,....

Otra cosa, Trata de poner las IPs de tus ordenadores en el archivo Hosts (c:\Windows\System32\Drivers\etc\hosts).
Cada ordenador debería tener su IP en su archivo Hosts. No debería ser necesario pero hay casos (como Interbase) en que el sistema va a buscar por toda la red antes de buiscar en el propio PC.

Slds.

En tu caso, deberias pensar SERIAMENTE en montar un sistema de Control de Codigo Fuente.

Ventajas?

- Estan diseñados para trabajar en red
- Permiter un acceso Cliente/Servidor al código
- Hacen automaticamente el merge de los cambios, guardan historicos del codigo (muy importante para cuando una cosa funcionaba en la version 0.8 de un unit pero no en la 0.9, puede verse cuales fueron los cambios y darse cuenta)

Uno muy popular es FreeVCS. El que uso y me gusta mucho (porque se integra dentro del Explorador de Windows, permite meter cualquier archivo y trabajar con cualquier herramienta de desarrollo en Windows o Linux, es gratis, MUY estable y bueno, y si se monta Apache, permite acceder a traves de INTERNET!) es Subversion (el servidor) y Tortoise (el cliente, instalar en cada maquina)

No gasta mas de un dia instalar con soporte Apache. Te recomiendo la ayuda que viene en Tortoise: No hay pierde posible.

No solo se te arregla el problema de la velocidad (porque cada programador trabajara sobre la copia local y luego la "sube" al servidor y "baja" las actualizaciones, incluso se pueden llevar el equipo/desconectar y trabajar tranquilamente) sino que ganas en seguridad (se puede integrar con seguridad de Windows) acceso a Internet (por ejemplo, descargarte el proyecto en casa o en un cliente, hacer cambios y subirlos, sin tener que trastear archivos) un mejor control de codigo (porque versionas) y backups instantaneos de los cambios (porque se guarda en una base de datos en el servidor) ademas de mejor disciplina al desarrollar; no mas: El desgraciado de Juan :mad: hizo un cambio y no deja compilar a Roberto, ya que Juan SOLO hace commit de los cambios cuando termina lo suyo y Roberto NO se afecta por Juan hasta que integre los cambios.

Por NADA del mundo permitan que el miedo o el desconocimiento les impidan explorar esta oportunidad! Es una forma facil y sin mucho estress de mejorar un desarrollo...

Te cuento que hace un poco más de un mes que comenzamos a usar FreeVCS, pues estamos trabajando dos personas en un mismo proyecto y ese programa nos solucionó el poder trabajar al mismo tiempo.
Lo que ocurre es que hay ciertas units que son básicas y que las utilizamos en nuestros proyectos, y por lo general no sufren modificaciones, es por eso que no las incluímos en el FreeVCS.
Lo que estamos probando ahora es colocar los .pas en un directorio y los .dcu en otro y aparentemente funciona, después les comento con más detalle si logramos hacer una mejora.

Muchas gracias a todos.

Guillermo

Que bien, pero estan haciendo a "medias" la cosa. Y de paso estan perdiendo varios beneficios....

Un CVS debe tener una copia de TODOS y CADA UNO de los archivos y recursos necesarios para compilar y desplegar el proyecto. Es MALA MALA idea lo que hacen porque es una manera muy facil de que se les corrompan los archivos de codigo o DCU (y luego que salgan errores intermitentes de Acces violation por un lio de la red, o lentitud, no sabran si es por causa de ustedes, la red o una libreria de terceros). Es lo mismo de malo de usar Paradox y Acces en un acceso de Red directo... Porque hacerlo si tienen un motor Sql como Firebird o Oracle? En su caso es lo mismo. Estan corriendo, por decirlo asi, "acces" por un lado y "Firebird" por el otro.

Si los archivos cambian muy poco, mayor razon aun para copiarlos localmente..... es una perdidad de recursos y un riesgo innecesario. Es como programar Cliente/Servidor: Las tablas que cambian muy poco, se cachean en el cliente para darle velocidad.

La idea es que dentro de cada root del CVS esta todos y cada uno de los archivos (codigo, formas, reportes, imagenes, Scrips de crear BD, documentacion, archivos ini de configuracion, etc...).ABSOLUTAMENTE TODO lo que forma parte del proyecto. TODO lo que se necesite.. si un archivo de Word tiene una explicacion importante, se mete tambien. No se preocupen: Los buenos CVS solo actualizan los cambios, no todos los archivos al hacerlo commit, y solo descargan los cambios tambien, a menos que sea la primera vez. Mas o menos, uno maneja estos 3 "proyectos"

- Codigo compartido.
- Archivos compartidos
- Uno por cada proyecto individual

Asi, hay minimo 2 descargas: El codigo compartido y el proyecto. Es benefico no poner todo junto porque la idea del codigo compartido es que sea eso, compartido, y el meterlo en un proyecto especifico es una gran tentacion a bastardizar el codigo...

Lo que DEMUESTRA que se estan haciendo bien las cosas, es que se debe poder en CUALQUIER momento, cualquier SEGUNDO, obtener una copia del CVS en un equipo y carpeta fresca, compilar y debe FUNCIONAR. Si no compila (la minima unidad de calidad) no es gracia, o falto un archivo (y lo meten al CVS) o estan dando COMMIT a codigo inestable (MAL hecho: Un CVS solo debe tener codigo estable, aunque no perfecto o sin bugs, pero si estable). De ahi, una vez que se logre la minima unidad de calidad si el desarrollo es grande y lo amerita (en este caso SI, hay muchos programadores) entonces se debe escalar a la segunda: Se debe poder generar ejecutables, dlls e instaladores y poder lanzar una version beta funcional (aunque no necesariamente correcta), o sea, hacer builds diarios o casi diarios, garantizando que cada build lanzado minimamente corre y abre y cierra el programa.

Es un beneficio lateral muy bueno. En mi caso, estamos haciendo un desarrollo largisimo que lleva ya 2 años. Ahora estamos en la recta final y los vendedores y testeadores, gerentes y clientes, necesitan con que "jugar". Antes de usar un CVS, me podia demorar hasta 1 mes en generar un beta. Un mes perdido para vendedores, gerentes, clientes y lo peor, testeadores. El mes de retardo era que si estaba en medio de un cambio interno, tocaba esperar a que todo se estabilizara de nuevo. Ahora, tengo la CERTEZA que puedo sacar en cualquier MINUTO una version Beta decente a quien me lo pida CUANDO lo pida y no al otro dia.... Porque puedo tranquilamente demorarme mi mes haciendo lo mio, pero en el CVS esta una copia estable, ademas hice un script con NAnt que me genera, compila, hace copia de seguridad y crea instaladores....

Muchas gracias, nuevamente.
Sos muy claro en tus explicaciones y me han ayudado muchísimo.
Voy plantear lo que me dices con los otros integrantes del grupo y veremos que hacemos, por lo pronto ya bajé el SubVersion y Tortoise, tendré que ponerme a ver como funcionan.

Hasta luego.

Guillermo