Your SlideShare is downloading. ×
[ES] Sistemas de control de versiones
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

[ES] Sistemas de control de versiones

1,880
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,880
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
76
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Sistemas de Control de VersionesEudris B. Cabrera RodríguezIngeniero TelemáticoDesarrollador de Software / Consultor InformáticoJunio 2013, Santiago de los Caballeros, R. D.
  • 2. Los conceptos y juicios de valor emitidos en esta presentación sonresponsabilidad personal y no se puede entender como una posiciónoficial de alguna empresa con la que he tenido relación laboral.Asuntos LegalesTodas las marcas registradas, así como todos los logotipos, imágenes,fotografías, audio y vídeos mostrados en esta presentación sonpropiedad de sus respectivos propietarios.Su utilización es solamente para fines ilustrativos y no pretendo dar aentender cualquier afiliación con esas empresas.Responsabilidades
  • 3. Contenido■ ¿Qué es un sistema de control de versiones ?■ ¿Cómo funciona ?■ Prácticas Obsoletas.■ ¿Porqué son necesarios ?■ Ventajas.■ Evolución.■ Principales sistemas de control de versiones de código abierto.■ Conclusiones.
  • 4. ¿Qué es un sistema de control de versiones ?Es un software que administra el acceso a un conjunto de archivos,y mantiene un historial de cambios realizados.El control de versiones es útil para guardar cualquierdocumento que cambie con frecuencia, como una novela, o elcódigo fuente de un programa.
  • 5. ¿Cómo funciona ?Normalmente consiste en una copia maestra en un repositoriocentral, y un programa cliente con el que cada usuario sincroniza sucopia local.Esto permite compartir los cambios sobre un mismo conjunto dearchivos.Además, el repositorio guarda registro de los cambios realizados porcada usuario, y permite volver a un estado anterior en caso denecesidad.
  • 6. Flujo de trabajo centralizado
  • 7. Prácticas ObsoletasSi alguna vez ha colaborado con otras personas en un proyecto, usted sabela frustración de constante intercambio de archivos.Los programadores a través del tiempo han usado diversos métodos paracompartir su código fuente en un ambiente de desarrollo colaborativo, acontinuación algunas de las soluciones más usadas:
  • 8. Realizar copias en diferentes computadorasMantener un backup en computadoras o servidores diferentes, asícomo también, guardar copia en disco compactos o disco externos.Si bien es cierto que ésta práctica puede mantener a salvo los códigosfuentes, también es cierto que tiene desventajas a la hora de guardarversiones.En cada modificación que hace al código original debe ir guardandotus propias copias de la versión anterior a la modificación y de la nuevaversión.
  • 9. Crear aplicaciones propiasCrear aplicaciones in-house para manejar las versiones de tu código,quizás sea una buena opción pero está reinventando la rueda, ya queexisten opciones open source para manejar versiones.El tiempo que debes utilizar para desarrollar una nueva aplicación paraestos fines puede utilizarlo en el desarrollo de otro proyecto.
  • 10. Guardar los fuentes en DropboxUna solución usadas en los últimos tiempos por los programadores.Dropbox internamente funciona como un manejador de versiones perotiene sus limitantes en el uso que puede darle un desarrollador.Las soluciones anteriores pueden tener su utilidad y dar resultadosaceptables, sin embargo, es recomendable usar una solución general,diseñada para mantener tu código a salvo y de forma centralizada,como lo hacen los sistemas de control de versiones.
  • 11. ¿Por qué son necesarios?En la sección anterior presentamos algunas prácticas usadas por losprogramadores y sus desventajas.Todos los sistemas de control de versiones tienen ciertascaracterísticas que eliminan muchas de las desventajas presentadasanteriormente, entre las cuales podemos mencionar:
  • 12. Actualiza archivos modificadosEl cliente recorre nuestro código y sincroniza nuestra copia local con elrepositorio.Copias de seguridad centralizadasSolo el administrador debe preocuparse de realizar copias deseguridad en el repositorio.Esto se automatiza fácilmente con una tarea cron [http://www.gnu.org/directory/cron.html] o similares.
  • 13. Historial de cambiosEl repositorio guarda registro de todos los cambios realizados.Es posible recuperar cualquiera de las versiones anteriores decualquier archivo.Si alguien borra todos los archivos, podemos volver atrás y recuperarsu contenido.
  • 14. Acceso remotoEs posible acceder remotamente al repositorio.No es necesario que el equipo esté dentro de la misma LAN.SeguridadEs posible otorgar diferentes permisos sobre diferentes ramas delproyecto.Por ejemplo, estableciendo permiso universal de lectura, y permiso deescritura sólo a ciertos usuarios.
  • 15. ¿Qué hacer cuando dos usuariosintentan modificar el mismoarchivo?
  • 16. Existen dosopciones ...
  • 17. 1. Bloqueos (Locks)El usuario bloquea el archivodurante su edición, evitando elacceso concurrente de otrosusuarios.Existen varios problemas:el usuario que acapara archivo,el interbloqueo entre usuariosque necesitan varios archivos,y la falta de concurrencia.
  • 18. 2. Merge (fusión de cambios)los archivos se accedenconcurrentemente.Los cambios realizados sobre unmismo archivo son fusionadosinteligentemente por el sistema.El único problema es el intentode fusión de cambiosincompatibles, que ha desolucionarse manualmente.
  • 19. VentajasLa mayoría de los desarrolladores probablemente han trabajado conalgún tipo de sistema de control de versiones, pero las personas enotras áreas pueden tener un concepto extraño.La ventaja más obvia de usar control de versiones es la posibilidadde tener un número ilimitado de personas que trabajan en lamisma base de código, sin tener que enviar constantemente losarchivos de ida y vuelta.
  • 20. Desarrolladores y otros profesionales que manejan archivos a loscuales se le realizan cambios constantemente, pueden beneficiarse deluso de los sistemas de control de versiones para guardar copias desus archivos, diseños, libros, etc.Usted puede navegar por los cambios anteriores realizado a surepositorio y volver a versiones anteriores si pasa algo.
  • 21. Evolución
  • 22. Principales sistemas de control deversiones de código abierto
  • 23. CVSConcurrent Versions SystemDesarrollador:The CVS TeamUrl:savannah.nongnu.org/projects/cvsLanzamiento inicial :19 de Noviembre de 1990Programado en C.Sistema operativo:Unix-like, WindowsLicencia:GNU General Public License (GPL)Esquema de trabajo
  • 24. CVSEs el abuelo de los sistemas de control de versiones.Fue lanzado por primera vez en 1986.CVS tuvo el mérito de ser el primer sistema usado por el movimientode código abierto para que los programadores colaboraránremotamente mediante el envío de parches.Es de uso gratuito, código abierto, y emplea fusión de cambios.Aunque CVS puede ser una tecnología antigua, todavía es muy útilpara realizar copias de seguridad y compartir archivos.
  • 25. SVNDesarrollador:Comunidad, y desarrolladores deCollabNet, Elego, VisualSVN, WANdiscoUrl: http://subversion.apache.orgLanzamiento inicial :20 de octubre de 2000Programado en C.Sistema operativo: MultiplataformaLicencia: Licencia ApacheFlujo de trabajo centralizado
  • 26. Subversion se creó para igualar y mejorar la funcionalidad de CVS,preservando su filosofía de desarrollo.Su desarrollo comenzó en el año 2000 como proyecto de códigoabierto apadrinado por CollabNet.El líder del equipo de desarrollo fue Karl Fogel, autor de Open SourceDevelopment with CVS y fundador de Cyclic Software (compañía dedesarrollo y soporte comercial para CVS.
  • 27. Probablemente sea el sistema de control de versiones con la adopciónmás amplia.La mayoría de los proyectos de código abierto utiliza Subversion comorepositorio.Google Code utiliza Subversion exclusivamente para distribuir código.Otros proyectos de mayor envergadura, como SourceForge, Apache,y muchos otros también lo utilizan.
  • 28. GITDesarrollador:Junio Hamano, Linus TorvaldsUrl:http://git-scm.comDiseñador:Linus TorvaldsProgramado en C, Bourne Shell,Perl1Licencia : GNU GPL v2Flujos de trabajo distribuidos
  • 29. Es la nueva estrella de los sistemas de control de versiones.Inicialmente diseñado y desarrollado por Linus Torvalds para eldesarrollo del Kernel de Linux, desde ese entonces, ha sido adoptadopor otros proyectos.Git se enorgullece de ser un sistema rápido y eficaz, muchosproyectos de código abierto importantes utilizan Git para alimentar susrepositorios, proyectos como: Linux Kernel, WINE, Fedora y muchosmás.
  • 30. Git ofrece un tipo de control de versiones diferente, un sistema decontrol distribuido de versiones.Con un sistema de control de versiones distribuido, no hay una solabase de código centralizada para tirar el código.Diferentes ramas sostienen las diferentes partes del código.Otros sistemas de control de versiones, como SVN y CVS, utilizar elcontrol de versiones centralizado, lo que significa que sólo se utilizauna copia original del software.
  • 31. GitHub ha ayudado recientemente a establecer Git como un gransistema de control de versiones, ofreciendo una hermosa interfaz paramuchos proyectos grandes, como Ruby on Rails, Netty y otros más.Sin embargo, Git no es tan fácil de aprender como CVS o SVN, asíque es mucho más difícil de usar para un principiante.Más información en:https://github.com
  • 32. MercurialDesarrollador:Matt MackallUrl: http://mercurial.selenic.comProgramado en Python y CSistema operativo:Tipo Unix, Windows, Mac OS XLicencia : GPL v2Esquema de trabajo
  • 33. Es otro sistema de control de versiones distribuidos de códigoabierto, como Git.Mercurial fue diseñado para proyectos más grandes, probablementefuera del alcance de los diseñadores y desarrolladores webindependientes.Eso no quiere decir que los equipos de desarrollo pequeños no puedeno no deben utilizarlo.Mercurial es muy rápido, y fue diseñado con el rendimiento como lacaracterística más importante.
  • 34. Aparte de ser muy rápido y escalable, Mercurial es un sistema muchomás simple que Git, por lo que atrae a algunos desarrolladores.No hay tantas funciones para aprender, y las funciones son similares alos de otros sistemas de CVS.También viene equipado con una interfaz Web independiente y ampliadocumentación en la comprensión de Mercurial si usted ha estadoutilizando otro sistema.
  • 35. BazaarDesarrollador:Canonical Ltd. y comunidadUrl: bazaar.canonical.comDiseñador: Martin PoolLanzamiento inicial:14 de diciembre de 2007Programado en Python, Pyrex, CSistema operativo:MultiplataformaLicencia:GPLv2 o superior1 (software libre)Flujo de trabajo
  • 36. Es otro sistema distribuido de control de versiones, como Mercurial yGit, que ofrece una experiencia de usuario muy amigable.Se llama a sí mismo "El control de versiones para los sereshumanos."Es compatible con muchos tipos diferentes de flujos de trabajo, conmuchas variaciones entre ellos.Se trata de un gran sistema de control de versiones para casi cualquierproyecto, ya que es fácil de modificar.
  • 37. También es integrable, por lo que puede agregar a los proyectosexistentes.Bazaar también tiene una comunidad fuerte que mantiene cosas comoplug-ins y un montón de herramientas de terceros.
  • 38. Bazaar es usado por miles de proyectos, incluyendo a :GNUBugZilla Debian LaunchPadLinux Foundation MariaDB Inkscape
  • 39. PopularidadZeroTurnaround Developer Productivity Report 2012
  • 40. RecursosCVS:http://cvs.nongnu.org/http://en.wikipedia.org/wiki/Concurrent_Versions_SystemSVN:http://subversion.tigris.org/http://code.google.com/http://www.beanstalkapp.com/http://en.wikipedia.org/wiki/Apache_Subversion
  • 41. Githttp://en.wikipedia.org/wiki/Git_(software)https://git.wiki.kernel.org/index.php/GitSvnComparsionMercurialhttp://www.selenic.com/mercurial/wiki/index.cgi/Tutorialhttp://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurialhttp://en.wikipedia.org/wiki/MercurialBazaar:http://bazaar-vcs.org/http://bazaar-vcs.org/Workflowshttp://doc.bazaar-vcs.org/latest/en/tutorials/using_bazaar_with_launchpad.html
  • 42. Conclusiones■ Desarrollar un software implica invertir mucho tiempo y dinero. Noproteger el código fuente con un sistema de control de versioneses irresponsable y puede traer graves consecuencias.■ Cualquier persona que trabaje con archivos que son sometidos acambios constantemente pueden beneficiarse del uso de lossistemas de control de versiones para guardar copias de susarchivos, diseños, libros, etc.■ Existen sistemas de control de versiones de código abierto, libredistribución y amplia documentación, lo que permite su fácilimplementación y curva de aprendizaje.
  • 43. ReferenciasDistributed Source Control Management systemshttp://blog.tfnico.com/2010/06/distributed-source-control-management.html7 Version Control Systems Reviewedhttp://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/Libro Version Control with Subversion (Ben Collins-Sussman, BrianW. Fitzpatrick, C. Michael Pilato).Ensayo "Subversion" de Alejandro Ramírez
  • 44. Email:eudris@gmail.comSkype:eudriscabreraLinkedIn:http://www.linkedin.com/in/eudriscabreraGitHub:https://github.com/ecabrerar