Implantando SVN en agencias

Hola gente!

Últimamente le vengo dando vueltas a un tema relacionado con el control de versiones (en mi caso subversion) y me gustaría oir opiniones y casos reales de uso por vuestra parte.

Normalmente el uso de svn en el area de programación no supone mayor problema: cada agencia/empresa/desarrollador utiliza sus propias nomenclaturas y formas de trabajar, pero el marco del uso de una herramienta para versionar está definido.

Actualmente estoy pensando en aplicar el control de versiones en todas las areas de mi agencia (desarrollo, diseño, copys, etc). Las razones son claras: centralizar archivos y contar con revisiones. Pero el tema me está generando muchas dudas.

Por ejemplo, hemos hecho algunas pruebas con diseñadores y no me acaba de convencer el resultado: psd's de 200 megas, cientos de imágenes, vídeos de gran tamaño... Cuando alguien se suma un proyecto porque tiene que tocar algún archivo es una locura tener que arrastrar todo eso.

Lo mismo pasa con presentaciones, textos finales, etc: se agradece muchísimo no tener que andar buscando quién tiene la última versión, no tener que pasar el material en sitios puntuales, que la persona lo olvide en su máquina local... pero con todo, he visto que hacer pasar a 20-30 personas (la mayoría no programadores) por este sistema es realmente confuso.

Pues eso, ¿cómo lo enfocáis vosotros? ¿SVN sólo para desarrolladores y el resto que lo haga de forma manual? ¿Todos a pasar por el aro? ¿Creáis diferentes ramas en cada proyecto para desarrollo, diseño, cuentas, etc? Me encantaría ver cómo lidiáis con este tema

Gracias por el tiempo!!
Un saludo

La verdad yo tambien tengo la misma pregunta. los archivos de texto no me importan, pero los archivos grandes no se si meterlos ahi... en mi server tengo muchos repositorios, algunos trabajos ya van por encima de la r5000 pero creo que en ninguno tengo ficheros que pesen mas de 5MB...

Quizas otra alternativa diferente a subversion...

Si tu agencia tiene una sucursal fisica y todos tus empleados van ahi a trabajar, con tener el svn en tu agencia (fisicamente hablando) no seria problema el tamaño de los archivos. Tal ves ahi tendrias una buena solucion.

Imaginate una vida sin subversion, igual tendrias que pasar archivos de gran tamaño, asi que no veo inconvenientes en ese punto.

Dientuki escribió:

Sí, la verdad es que estamos todos en el mismo lugar. Y en cuanto al espacio en disco y el tamaño no es problema.

Supongo que me cuesta enfocar este tipo de herramienta para todas las areas y por eso me surgen bastantes dudas. Pero bueno, será cuestión de tirarse al río e ir solucionando sobre la marcha.

Saludos!

Cuentanos tus experiencias.

La verdad nosotros solo manejamos SVN para ciertos proyectos o partes de un proyecto, no para todo, es decir, nos apoyamos en SVN mas que todo para proyectos donde haya mucho codigo y hay mínimo 3 personas dando una mano a este mismo. El SVN lo usamos remoto, esto casi que nos obliga a optimizar todo, desde los archivos fuente .psd o .png hasta el mismo código. Esto pues es realmente bueno porque repito casi que OBLIGA a optimizar todos los aspectos, sino, puede tener un efecto casi contrario al de ayudar.

Para las cosas que no requieren tanto codigo y son mas ilustrativas, como plantillas, sketch's, videos, etc, lo que hacemos es que se dividen las tareas, se deja en cabeza de una sola persona y es quien al final tiene la responsabilidad de subir los archivos al servidor local. Esto lo hacemos entre otras cosas para que cada persona sea responsable de una parte y responda por esa parte y no que todo el proyecto ande de mano en mano por todo el equipo. Repito, SVN para el código es excelente porque quien gerencia el proyecto sabe quien hace que, cuando, etc, lo que ustedes saben que hace SVN, pero con la parte gráfica es mejor dividir (en nuestro caso) el trabajo en partes lo suficientemente pequeñas para que cada elemento del equipo lo pueda desarrollar y luego hacer reuniones pequeñas (muy cortas) donde se unifican los criterios y se unifican los resultados. Y ya ese es el resultado que queda para el archivo local.

Como comentario final diría que no hemos pensado en el manejo del SVN en el servidor local para toda clase de proyectos, no lo hemos visto necesario, por eso también quedaré pendiente de las experiencias de ustedes.

Salu2

Si de todas maneras tienen que enviar los archivos (PDF, PNG, PSD) por red, da igual usar Subversion o FTP o lo que sea.

Incluso me parece más eficiente y cómodo con el tortoiseSVN que con un FTP o con el correo.

En cuanto a espacio en disco, en la documentacion de subversion dicen: los archivos binarios se guardan de manera MUY eficiente en el repositorio, no se guardan muchocientas versiones sino una versión y los deltas.

Y el tortoise Diff muestra diferencias entre imágenes.

Ya diferencias entre documentos de word o excel o PDF, se deben ver con una herramienta externa.

Y finalmente: Ya salió la version 1.5 con soporte para merge tracking.

PD: revision 5000 ??? Es que hacen ahí todas las pruebas??? Yo ando en las 400 revisiones hasta ahora.

Shorel escribió:

Sí, este punto es muy cierto, y la verdad es que svn optimiza mejor el espacio en disco que si dejas tal cual los directorios y archivos. Aunque quizá la forma de trabajar de andresmaro la veo más cercana a lo que tengo en mente (con algunas diferencias).

Supongo que mi problema es más a nivel de filosofía, sobre el uso real de la herramienta más allá del versionado. Hoy un diseñador me comentaba que porque no meter las tipos (arial, verdana, etc) que usa cada proyecto en el subversion. Puedo entender lo apetitoso que es sumarse a un proyecto y saber que en el cliente XXX tienes todas sus fuentes correspondientes. Pero claro, esto únicamente lo harías porque así tienes todo centralizado y es muy cómodo, pero una tipo nunca se versiona. Así que pienso, "pues las tipos en carpetas compartidas en el servidor y que la gente las saque de allí".

Eso me lleva actualmente a estar pensado en dos ramificaciones: las cosas que se versionan (código, psd, etc) y las que no (tipos, videos, material cliente). Lo veo más ordenado, pero vuelvo a lo mismo, entiendo que para el resto de gente sea más cómodo acceder a un único punto central y tenerlo todo.

En fin, que hasta en este punto de duda me encuentro...
Gracias por vuestros coments!

En nuestro caso la parte visual suele ser resuelta desde los conceptos básicos con conceptshare. Esto con el fin de hacerlo más flexible visualmente. De hecho la parte gráfica suele ser mucho mas subjetiva que la parte de código, por lo menos cuando no todos los procesos de codificación siguen estándares, sino, se puede volver mucho mas subjetivo que el desarrollo conceptual de una imagen. Y digamos que conceptshare permite tener el historial de comentarios que es bueno para el resultado final que algunas veces, no todas, hacen parte del repositorio de un proyecto.

En nuestro caso hemos intentado varios servicios incluyendo activecollab, conceptshare, y otros basados en web (ya que trabajamos de forma remota).

Todas en la gran mayoria no funcionan por simples motivos, no puedes llevar un historial + log de versiones, ver las diferencias entre versiones y el peor de todos, no puedes subir un archivo pesado (normalmente no más de 3MB).

Personalmente ya usaba SVN en proyectos libres como Jaws, jQuery, y UI asi que le di una oportunidad.

Después de ya algunos meses debo decir que la productividad ha mejorado, estamos mejor organizados, llevamos un record de lo que se trabaja, cuando y en exactamente qué proyecto, además de tener un backup centralizado. Es genial.

Pero no todo es felicidad. Siempre existen los conflictos, y SVN no es exactamente el mejor sistema de versiones que existe, debido a una limitación de fábrica SVN no funciona "bien" con archivos binarios. Y en cada "commit" no agrega un "parche" con los cambios hechos al archivo (como en todos los archivos de texto), sino "sube y sobreescribe" todo el archivo una y otra vez en cada commit.

Es decir, si tienes un archivo .html de 10KB y el nuevo pesa 11KB, tu base de datos del SVN posiblemente solo aumentará 1KB. Mientras que si subes un archivo binario de 10MB, y una actualización de 11MB, el SVN será de 21MB aprox.

Lastimosamente esto es de fábrica y nunca estuvo pensado para editar binarios asi que no es exactamente un "error". Mientras que otros sistemas de versionamiento más poderosos si lo soportan, uno de ellos es Git y su port a Python, Mercurial.

Normalmente Aqt maneja SVN de este modo:

Código :

/proyecto/  (root del proyecto)
/proyecto/design  (los psd, ai, png y jpg de exportación)
/proyecto/dev  (todo el código del site, html, js, php, etc.)
/proyecto/resources  (imagenes y fotos de alta resolucion, videos, fonts, etc, normalmente no se "versionan" pero se guardan en el repositorio)

Asi los diseñadores solo necesitan bajar la carpeta design de cada proyecto al que se suman, el desarrollador solo dev o alguna subcarpeta, y resources es opcional.

Cabe recalcar un punto muy importante para que el versionamiento realmente te "funcione". Nunca hagas un commit por gusto, siempre haz un commit cuando haz hecho un cambio sustancial e importante, y/o basicamente terminaste una tarea. Crear un módulo, un nuevo feature, un bugfix, etc.

Si tu haces un commit cada 5 segundos, tendrás 9000 revisiones en un repositorio con 2 proyectos, en menos de 1 mes. Esto no es óptimo, y además cuando quieras hacer un rollback, no sabras a donde hacerlo.

Otro punto clave es siempre escribir un mensaje descriptivo en el log, ya que este funciona como el título de los posts en cristalab, si no es descriptivo no sabras que es y no podrás ver facilmente qué version es la que buscas.

Un dato extra, si sabes SSH, y tienes un servidor remoto no hay nada mejor que entrar al servidor de hosting via shell, y escribir lo siguiente.

Código :

svn export svn://tuhostingdesvn.com/proyecto/dev public_html

Normalmente, tomará menos de 1 min y ya tendrás todo el site completamente funcional. Para mas datos de mejorar la productividad con SVN busca sobre hooks, trac, y optimización de repositorios.

Suerte.

Genial NEO, un post superdetallado, se agradece mucho

Me has dejado un poco frío con el tema de los archivos binarios, no sabía que tenía "problemas" para manejarlos. Me lo miraré con calma. Pero por encima de todo me quedo con:


En cuanto a la estructura lo tenía pensado igual que tú pero sin la carpeta "resources" ya que como dices, hay archivos que por naturaleza no se versionan (videos, fuentes, etc) y me genera dudas: ¿dentro o fuera? Es el único punto que tengo que estudiar.

Gracias a todos por los aportes!

NEO_JP escribió:

¿Han revisado Capistrano? Es una delicia implementarlo cuando se apoya con el svn para realizar los deployments.

Estoy preparando unos artículos de como trabajamos en mi empresa, donde hablaré de las herramientas que usamos y que probablemente les pueda servir a varios y estoy en proceso de animar a otras empresas similares para tener un repositorio interesante. A ver si se animan

Yaraher escribió:

... Interesante, desde que no pierda cierta privacidad (por lo menos usuarios cristalab(tm) ), puede ser muy interesante...

llops escribió:

Tomado del SVN FAQ:


Hay que tener en cuenta qué es un archivo de diferencias, y cómo afectan los archivos originales un diff. En particular aspectos como la compresión.

Todos los archivos tienen cierta 'entropia de información', donde la información redundante tiene menos valor que la información única, por ejemplo, un archivo de texto plano tiene muchas palabras repetidas como 'el'.

Esta entropía se afecta al comprimir los datos, ya que la compresión esencialmente elimina toda información repetida y redundante en un grupo de datos. Un pequeño cambio en el archivo original, sobre todo al inicio del archivo, hace que el contenido de todo el archivo comprimido sea diferente.

Entender esto es fundamental a la hora de generar los diffs.

Los archivos comprimidos no pueden ser comparados exitosamente por un algoritmo de diferencias, ya que una pequeña diferencia en los datos originales genera grandes diferencias en los datos comprimidos. En la práctica esto implica que un archivo de diferencias pueda llegar a ser incluso igual de grande que el archivo original.

Estos archivos comprimidos son ZIP, RAR, JPG, GIF, PNG, MP3, etc. Cuando el tipo de compresión permite perdidad de datos, como en los JPG y MP3, los efectos son incluso más pronunciados. Esto sin tener en cuenta que un archivo comprimido no se puede comprimir más. A lo sumo se ganarán unos pocos bytes y ya.

Si se tienen los datos en un formato binario que no use compresión, no existe este problema con los archivos de diferencias.

Por ejemplo: los ejecutables no cambian todos sus bytes al ser recompilados y pueden ser comparados exitosamente, guardándose archivos de diferencias más eficientes en su lugar.
Los documentos de Word, al ser un volcado de las estructuras de datos de Word en memoria, tampoco usan compresión y pueden ser comparados generando pequeños archivos de diferencias.

Por ejemplo, en un archivo binario de un .exe que almaceno en uno de mis repositorios tengo estos datos:

• Importacion inicial= 500Kb
  
• Revision n = 240Kb
  
• Revision m = 250Kb
  

El archivo original (afuera del repositorio) es de 1Mb. Esto representa un significativo ahorro de espacio, uso aproximadamente el 33% de lo que usaría almacenando los archivos fuera del repositorio.

Ahora, ¿porqué menciono esto en el post?

Respuesta: porque sin importar lo eficiente o poderoso que sea el archivo de diferencias (binarias o de texto), debido a la entropía de la información simplemente hay cosas que no puede hacer. Esto no es una limitación de SVN, sino una limitación algorítmica fundamental.

Shorel escribió:

Owned.