Eleanor Roosevelt, siendo primera dama de Estados Unidos y de visita oficial en Argentina, al contemplar la belleza de las cataratas del Iguazú sólo pudo exclamar «¡Pobre Niágara!». Es una exclamación muy normal cuando se te rompen todos los esquemas conocidos. En la cuadriculada cabeza de Eleanor no cabía belleza superior a sus amadas y conocidas cataratas del Niágara y sin embargo las del Iguazú superaron salvajemente sus expectativas. Algo así pasa cuando conoces Git .
Tras haber trabajado con Source Safe, CVS y Subversion de forma esporádica, me pasé a Perforce teniendo la firme convicción de que era lo mejor y lo único bueno en cuanto a SCM se refiere. Tras 4 años usando este entorno propietario (y carísimo), más por necesidad que por ganas de cambiar, empecé a buscar un SCM gratuito (y libre a poder ser). La tendencia entre los programadores parecía llevarme de forma irremisible hacía Git, un nuevo concepto de SCM en el que las jerarquías se desvanecen para dar paso a una especie de light-SCM en el cual todos los nodos del sistema son igualmente importantes y contienen toda la información para ser totalmente autónomos.
Esto abre un mundo de posibilidades y ventajas:
-
Se aumenta la velocidad al trabajar casi siempre en local.
-
Se reduce la necesidad de estar siempre conectado.
-
Se aumenta la fiabilidad del sistema al tener todos los nodos una copia completa del proyecto.
Otra gran ventaja por la que supera a todos los demás SCM que he conocido es el manejo de ramas y etiquetas. En mi ex-favorito SCM, Perforce, el tema de las ramas era complicado y pesado: cada vez que creabas una rama se creaba una nueva copia de todos tus fuentes tanto en el servidor como en local. Con Git crear una rama es inmediato y no requiere ninguna copia. Ni hablar ya de las etiquetas, algo que Perforce ni siquiera soporta.
¿Problemas? Pues sí, Git hoy por hoy, adolece de un gran problema: la facilidad de uso. Aquello que con Perforce está clarísimo, en Git es muy fácil, pero «hay que saber hacerlo». Un par de proyectos empiezan a iluminar el camino de los usuarios de Git: Git Extensions y TortoiseGit. El primero es un acertado GUI que rompe con todo lo conocido en el software libre y se acerca a la facilidad de uso de Perforce (sin todavía alcanzarlo ni de lejos) y el segundo es un re-frito del TortoiseSVN que todavía está en pañales. Ambos son muy recientes, pero muy prometedores. Esa es otra guerra, ¿conseguirán estos GUI arrebatar a Perforce a los usuarios que sólo buscan la facilidad?
No seguiré con la comparación entre Git y Perforce. Sólo diré que le faltan pocas características a Git para ser mi SCM soñado y algunas de ellas se pueden solucionar mediante scripts (¿he dicho que Git es altamente configurable? mucho más que P4). Tengo la teoría de que todos los programadores que hemos trabajado mucho tiempo con sistemas de control de versiones nos hemos planteado como sería el ideal. En mi caso hasta estuve a punto de programar uno. Ahora viendo Git lo único que se me ocurre es sugerir las pocas mejoras (GUI aparte) que necesita para ser perfecto. ¿Cómo seria tu SCM ideal?
3 respuestas a «Git: ¡Pobre Perforce!»
Yo usar usar, he usado el CVS, Subversion, Mercurial y Perfoce.
Para mi, la razón numero 1 por la que perforce supera a todos estos otros es básica y llanamente, porque el interfaz de usuario está superbien pensado y estructurado, da muchisimas facilidades al programador, y le ahorra bastante tiempo en el día a día.
¿Calidad/precio compensa? Probablemente si no te sobra el dinero, mejor buscar alternativas, como pueda ser Git, pero si tu organización tiene mucha pasta, la verdad es que funciona muy bien.
¿Problema gordo de perforce? Que no está preparado para trabajar sin red.
Por ejemplo, hace un par de años (no se si el interfaz habrá mejorado), estube usando RapidSVN, que si bien un interfaz decente para subversion, le faltaban las 4 chorradas que hacen que perforce sea fácil.
En cuanto a los sistemas de control de versiones distribuidos, no he usado Git, pero he usado Mercurial, y la conclusión que sacado hasta ahora es que las UI de mercurial son un poco (por no decir mucho) malas. Arquitecturalmente hablando, no me gusta el concepto de que haya varias copias, porque al final, si hay muchos desarrolladores, no se puede contestar a la pregunta de ¿donde está la última copia? Es un caos, y al final se tiene que optar por un modelo donde haya un servidor que sea donde toda la gente aplique los cambios, y al final estás usando un SCV (Sistema de Control de Versiones) distribuido, como si fuera uno de toda la vida, y la única ventaja real que te aporta es que cuando se te desconecta el ordenador de internet, puedes seguir trabajando y submiteando como si nada. En cuanto al manejo de ramas en el Mercurial me parece un caos, probablemente porque me falte ver la herramenta GUI que los ordene y me lo muestre todo bonito.
Seguramente me falte algo de educación en cuanto a usar sistemas de control de versiones distribuidos, porque igual lo que he dicho no es así, y estoy aplicando mal las ideas. En cualquier caso, aunque soy un poco excéptico al respecto, tomo nota del Git para ser tenido en cuenta en un futuro. Si todo el mundo dice que es cojonudo, una de dos, o realmente lo es, o les han lavado el cerebro.
Yo hasta el momento creía que era la segunda, pero si tú Ivan piensas que es la ostia… habrá que verlo.
Se me olvidó comentar en el artículo que cuando digo que Git no tiene un buen interfaz de usuario me refiero a su versión para Windows. En Linux dicen que hay un tal Git Cola que funciona muy bien, pero no puedo opinar.
Perforce es cierto que es muy facil de usar cuando quieres hacer cosas «normales», pero en cuanto tienes que hacer algo complicado tienes que acabar en la línea de comandos o en uno de los inexplorados menús que tiene. Un ejemplo muy sencillo, ¿que pasa con P4 cuando después de haber enviado 15 bugfixes tienes que volver atrás e implementar un cambio especifico para una determinada versión? ¿y que pasa si unos meses más tarde tienes que consolidar ese cambio con todo lo que has programado desde ese momento? En Git eso es una tarea de 4 clicks de ratón (a pesar de su horrible interface).
En algo sí que te doy la razón: todavía no le veo la ventaja a tener repositorios totalmente descentralizados. Supongo que es por el tiempo que llevo con repositorios centralizados, pero no se me ocurre ninguna ventaja para no mantener repos centrales. Eso sí, hay muchas razones por las cuales me encanta que cada instalación de Git pueda ser el repo maestro o no (y no solo el poder trabajar offline, tambien la facilidad para hacer deployments, la escalabilidad, la seguridad…)
[…] lo hubierais hecho con vuestro SCM favorito? Lo dicho, ¡pobre Perforce! […]