EDICIóN GENERAL

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

Y por esto chavales hay que gastarse los jurdeles en sysadmins pr0s que configuren el GIT, los usuarios y sus permisos con suficiente granularidad pa que no jodan la empresa!! :troll:
#3 que GIT ni que niño muerto,SVN,y si hay conflictos override and commit siempre.
#4 ARggg puto SVN ni te imaginas como la liaban parda los desarroladores con los branches, con rollbacks que no funcionaban, etc. La liaban tanto que tuve que meter crontabs pa pillar snapshots cada hora del puto /var/lib/svn (aparte de los backups estándar, ofc). Lo que mola de GIT es que "pa tontos" (o desarrolladores que no saben ni bash, ni consola, ni pollas usar su puto ordenador) :troll:
#8 ¿Os la estáis midiendo?
#23 creen, que se la están midiendo
#25 la tienen pequeña.
#26 ojo, que uno de los que sabe hace backups de un sistema de control de versiones, porque los desarrolladores la liaban con branches y ¿rollbacks? Que no funcionaban. No se a cual despediría antes al que usaba backups para recuperar versiones o al de los "rollbacks" del control de versiones
#28 Los backups no son pa recuperar versiones, eran pa recuperar todo el puto directorio del repositorio /var/svn/reponame una vez que la había liado con los rolbacks de las versiones del SVN y se llegaba a un punto que "ni patrás ni p'alante", cosa que deberías saber si has usado SVN alguna vez. Con GIT es mucho más fácil hacer rollbacks y gloria bendita y fácil manejar los branches. Un desarrollador que no tenga soltura con la consola (los típicos que usan el nano en lugar de vim/emacs) es carne de cañon pa liarla con un repo SVN, cualquier viejuno sabe esto :-P

#23 #25 No medimos nada, estamos tanteándonos. Cosas típicas que hacen los BOFH ;)
#29 En 20 años trabajando no he visto ninguna empresa que deje tocar a nadie la estructura de directorios del repositorio. Se les deja hacer check-out, commit, updates, revert, y opciones de historial, etc., que tocan solo versiones. He visto a gente borrar el trunk, y como sabrás, eso solo es otra versión en el mismo que no necesita recuperar un backup, no necesitas ayuda de nadie.

Así q sinceramente yo os cortaba la mano a vosotros por dejarles tocar la estructura de directorios de los servidores de Svn {0x1f601}
#29 La gran mayoria de desarrolladores que conozco yo ni si quiera han tocado nano. No han tocado un sistema linux en su vida.
#23 Ahí están, a la espera de un hilo en que se mencione algo de informática para demostrar que son alguien.
#45 Chico pues como todo el mundo. ¿O no pasa lo mismo con los abogados, los técnicos en paneles solares o los biólogos cada vez que se habla en un hilo de lo suyo?
#46 En los informáticos yo veo (y no soy el único) un especial medimiento de polla. Noto un especial interés en usar un término que el otro no entienda.
Y que conste que soy técnico superior por partida doble, en sistemas en red y en desarrollo de aplicaciones web. No es que vea términos comunes y al no saber, no los entienda.
#8 Git es "pa tontos" si te limitas al clone/pull/commit/push, y tienes una política de ramas y merges medianamente decente. En mi último trabajo no la teníamos, y vi a cada uno liar unos cristos con el Git...

Pero muy de acuerdo en que SVN es mucho peor. Donde estoy ahora llevaban años usando SVN y tenían el repo echo un desastre, porque no sabían gestionar las branches (que en SVN son una mierda por otro lado), y habían reorganizado el árbol de directorios como les había salido de las pelotas. Ahora estamos pasando todo a Git, y es mucho más sencillo.
#8 El SVN un lío con los branches? GIT me parece mucho más lioso con branches por todos los lados cuando lo único que quieres es subir algo a develop. Si quieres actualizarte un fichero no puedes, tienes que actualizarte todo o nada, resolver conflictos complicado. El histórico es incomprensible, pues te mezcla tus cambios con los "merges" y aparecen cambios de otras personas como si fueran tuyos...
#39 ¿ No puedes actualizar un fichero haciendo fetch (que no pull) y luego checkout de ese archivo desde remote/branch ?
#8 #27 RESOLVE WITH MINE!!!
#68 Como lema para la vida :-D
#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:
#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.
#3 Si, pones en marcha toda una pila de medidas de seguridad y luego vienen los jefes de equipos pidiendo que se relajen tales o cuales medidas. Como ellos son los importantes para los directores se les conceden sus peticiones, mas que nada porque los que deciden no tienen ni idea, ni quieren explicaciones. Añade tiempo a la ecuación y al final tienes el sistema todo oradado y la información comprometida. Total "si no pasa nada", hasta que pasa y entonces es culpa tuya que eres el que siguió las ordenes.
#3 O no contratar chinos que luego se van a trabajar con los chinos llevándose los secretos tecnológicos de los malvados capitalistas. Ah no, que esto sería "racismo".
#3 Envía el CV a Tesla. Y tardas. Seguro que allí son todos unos inútiles y en dos días te hacen consejero.
#62 JUASSS! Echa tu el CV que se te ve que vales para un puesto de manager: mucha palabra y poco contenido. Que apechuguen y aprendan que lo barato sale caro. Si se hubieran gastao los cuartos en ingenieros en condiciones y/o sysadmins potentes otro gallo hubiera cantado. Si quieres profesionales buenos hay que pagarlos, querido manager! ;)
#63 Yo no soy un manager, soy un manganter.
#64 No esperaba menos de ti, rey ;-D

menéame