EDICIóN GENERAL

Un ex empleado de Tesla se descargó el código fuente del autopilot, y ahora trabaja en una compañía china

#4 Ah, pero tiene más comandos? :-D

Hace tiempo que ya no se ven aquellos debates SVN vs Git. Ahora cuando alguien menciona SVN sólo se ven madres corriendo asustadas a alejar a sus niños de ese señor.

O como dijo Linus Torvalds en una charla sobre Git: "si hay algún usuario de SVN en la sala quizás quiera marcharse" :troll:
#8 #27 RESOLVE WITH MINE!!!
#68 Como lema para la vida :-D
#27 git es perfecto para gente como Linus, que quiere revisar todo lo que le hacen a su hija y decir si puede quedar con ella a tomar algo o solo mirarla desde el cristal de la puerta, tiene ventajas sobre SVN, y tiene inconvenientes también. Es el presente/futuro? Puede que si, puede que no, pero de ahi a decir que SVN no sirve, solo se puede calificar de ignorancia.

En cuanto a la gestión de branches, decir q SVN no sirve, es otra muestra de ignorancia
#73 No conoces Git, eh? ;) No te preocupes, hombre, que es más sencillo de lo que parece. Dedícale sólo algunas tardes sueltas y podrás unirte al club de "madredediós, pero qué puta mierda era el SVN" :hug:

Seguro que conoces a mucha gente que ha pasado de SVN a Git... y a nadie que haya seguido el camino inverso. Pero es normal, Git es posterior a SVN e implementa soluciones a problemas que sólo se fueron viendo con el uso. Es ley de vida en el desarrollo de software.

Y precisamente si en algo Git es aún más superior (sic) a SVN es en el branching.
#74 si, conozco git, si también presenta problemas con los conflictos, la gestión de conflictos siempre presenta problemas cuando gestionas muchos grupos de gente desarrollando sobre los mismos ficheros muchas versiones en corto tiempo. Si, SVN gestiona branches bien, si lo haces bien. De hecho las gestionan de distinta forma y por eso no se gestionan de la misma manera, es más, el trabajo en equipo no surgió con Git.
Git es una evolución? Claro como dices se pensó para resolver muchas deficiencias de CVS y SVN. SVN no es una puta mierda como otras no lo fueron en su momento, simplemente son herramientas q resolvían un problema y el software evolucionó posteriormente para hacerlo mejor adaptándose a nuevas formas de trabajar
#75 Pues entonces estamos de acuerdo. Esto no es una batalla de el Bien contra el Mal. Simplemente SVN fue muy superior a otras soluciones en su momento, pero Git (como Mercurial) nació precisamente para resolver algunos problemas que presentaban CVS/SVN y otros VCS cuando el equipo de desarrollo de Linux decidió abandonar BitKeeper por cuestiones legales.

Y mañana saldrá otro VCS que solucionará algunos de los problemas con los que cuenta Git (que son varios) y lo eclipsará, y así sucesivamente...

Y no dudes que cuando salga este nuevo VCS mucha gente se aferrará a Git diciendo que es la puta polla, porque es el que conocen, y que el nuevo VCS no es mejor, sino sólo distinto. La resistencia al cambio es una constante de gran parte de la humanidad.

Y por supuesto que Git presenta problemas con los conflictos (de ahí que se llamen "conflictos" :shit: ) pero tiene herramientas mucho más sofisticadas de SVN para resolverlos.

Del mismo que, si bien SVN permite trabajar con branches, el concepto de branch de Git (que no se confunde con el de directorio como en SVN) está a un nivel muy superior, sobre todo cuando necesitas trabajar con varias ramas en paralelo.

Hay un breve texto, es de un manual de Mercurial pero se aplica igualmente a Git, "Subversion Re-education", que explica con mucha claridad algunos conceptos que suelen confundir a los usuarios de SVN cuando empiezan con Git o Mercurial.
#76 Es gracioso el artículo, habla del problema más grande que hay también en el paso a Git, el cambio de chip de svn a git.
Esa pequeña curva de aprendizaje, provoca mucho rechazo en cambiar, y solo si la empresa de verdad "obliga" a cambiar de repositorio, esa curva es superada.
Ya lo he visto varias veces, pero más veces he visto volver atrás porque ni la empresa ni los desarrolladores querían arriesgarse en proyectos ya en marcha.
#77 Ahí te doy la razón. En un proyecto en marcha, con desarrolladores que conocen SVN pero no Git, cambiar un repositorio a Git podría traer más problemas que ventajas. Sobre todo teniendo en cuenta que se puede interactuar con un repositorio SVN a través de un cliente Git.

No te voy a negar que la curva de aprendizaje pueda resultar un tanto empinada al principio para los que provenimos de otros VCS. Yo pasé una época copiando y pegando comandos Git de un cheatsheet que me fui haciendo sobre la marcha sin saber muy bien qué estaba pasando por debajo.

Fue a raíz de entrar en un proyecto ya iniciado, en el que el anterior coordinador había cometido la temeridad de dar permisos de push a master a todo el mundo, y de encontrarme que uno de los bare repos estaba bastante por encima de los 200 MB (vale que el de Facebook sean 15 GB :shit: pero en este caso era una barbaridad) que me vi en la necesidad de conocer cómo se estructuraban para intentar eliminar lo que sobraba sin perder el log.

Y la verdad es que resultó mucho más sencillo de lo que esperaba. Una vez que uno conoce los "three trees" (HEAD, index y working directory) todo cobra sentido y empiezas a obtener un conocimiento intuitivo de cómo manejar el repositorio. Aunque por supuesto después vas aprendiendo pequeños trucos y maneras de hacer lo mismo de manera más eficiente.

Con el paso del tiempo he ido gitificando todo lo gitificable :-D y ahora tengo repos versionados no sólo de software, sino también de documentación de todo tipo, binarios (con Git-LFS), proyectos multimedia, ficheros de configuración... Y créeme que es una maravilla que me ha ahorrado mucho tiempo y quebraderos de cabeza.

Y además de todo esto, a nivel profesional, un buen conocimiento de Git es cada vez más importante.

menéame