#14Torvalds has quipped about the name git, which is British English slang meaning "unpleasant person". Torvalds said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.
Lo mismo digo. Pagaría una cantidad aceptable por aprender bien como se utiliza de manera correcta y sin miedos a reventar el proyecto
He leído muchos tutoriales y o bien llego a la conclusión de que soy tonto por no entenderlo bien o liarse cuando se trabaja con varias ramas es algo normal
Git es muy potente, pero tal vez sea demasiado potente. Torvals lo desarrolló para controlar el desarrollo de Linux, lo cual son palabras mayores. Lo de las ramas, subramas y demás son perfectas para un desarrollo tan complejo como el de un kernel. También los mecanismo que tiene para evitar que programadores con buena fe pero no demasiado conocimiento te jodan el trabajo.
El problema viene cuando una empresa pequeña usa Git para un proyecto en el que trabajan un grupo reducido de programadores. Demasiado complejo. Lo suyo sería usar Subversion. Pero claro, "lo que mola" es Git.
Torvalds has quipped about the name git, which is British English slang meaning "unpleasant person". Torvalds said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.
He usado cvs, svn, bitkeeper y Git.
En todos saco las mismas conclusiones
Da igual lo poderosa que sea la herramienta, la estupidez humana la supera
Lo importante es s tener un juego de tests que todo el mundo pruebe antes de Git push.
#15 SVN es facil de utiilizar, pero cuando algo va mal, es un infierno para un usuario inexperto. El motivo principal, que no puedes mover archivos por el proyecto a tu antojo, ya que contienen carpetas ocultas que se desaparecen se va todo al traste. Tampoco puedes meter un archivo de otro proyecto en el tuyo sin hacer un export correctamente.
Nuestra experiencia en el cambio de SVN a GIT en la oficina ha sido una reducción de casi la totalidad de incidencias de sistema de control de versiones.
A lo mejor es pq no soy un friki de la consola,ni de estudiarme un libro para gestionar el codigo, pero me sorprende que nadie haya mencionado gitextensions . Adios peleas con git.
#7 No. Subversion es una puta mierda y prefiero usar git en un equipo de tres personas antes que svn. Cuando en mi oficina empezamos a usar git, sólo yo sabía. Enseñé lo básico, pasé links de lectura obligada y en menos de un mes ya teníamos menos problemas integrando que con svn. Alguna vez me toca hacer algún rebase, pero eso es normal. No ha vuelto a haber ni un solo merge hell desde que cambiamos a git.
#15 SVN no es mejor ni para proyectos de andar por casa. Con git, con que sepas hacer git add . git commit y git push vas sobrado para trabajar en tus proyectos personales, mantenerlos en GitHub (o BitBucket o donde quieras) y vas a tener un control de versiones más férreo.
Echad un ojo a git flow. Añade una capa por encima que permite seguir un Orden. Aunque si eres un marrano puedes seguir guarreando en el master.
Yo tengo un master resolviendo conflictos de mi compañeros y no soy asistente social danielkummer.github.io/git-flow-cheatsheet/
#7 Yo lo veo al contrario, habiendo utilizado Subversion y Git. Una vez tienes en la cabeza la idea del GitFlow (master/develop, hotfixes, releases y features) todo se queda muy ordenadito, y tienes herramientas como SourceTree en Windows o SmartGit en Linux que te lo hacen todo solo, te montan las ramas del GitFlow y hasta te pintan los diagramas.
Y si te resulta muy complicado te quedas en la develop y ya está, que al final es lo que pasa cuando te pones a desarrollar y se te olvida crearte una rama, y tampoco nadie muere por ello.
El único problema que nos ha llegado a dar ha sido con proyectos web porque se nos líen los permisos de las carpetas del repo al automatizar procesos de la web y que se creen cosas con permisos del apache tal que al intentar hacer Pull no sea capaz de escribirlo en parte. Pero al final te pegas un poco y lo apañas.
#21 O Sourcetree en caso de Mac. Nunca entenderé a esa peña que tiene que usar la consola si o si, escribir 3 líneas de comando en vez de pulsar un botón en una UI.
Como casi siempre, el problema no es la herramienta, los que tienen problemas con el control de versiones no es porque no entiendan git, es porqué no entienden como gestionar las versiones de un proyecto y porqué hacen lo que están haciendo. Lo fundamental no es si uso git, mercurial o svn, lo fundamental es si hago main line development, hago feature branching etc,etc y porqué hago esto en función del tipo de desarrollo y de las necesidades que tengo. No es lo mismo hacer una librería o un producto del que tengo que soportar N versiones vivas al mismo tiempo que desarrollar un sistema en el que sólo tengo viva la ultima versión, tengo que pensar en el balance entre tener ramas y hacer mis integraciones menos frecuentes o tener una única rama y integrar de forma constante, tengo que pensar si tengo o no una estrategia de despliegue continuo y como afecta la politica de ramas a esa estrategia etc,etc.
Luego, cuando uno tiene los conceptos claros y sabe lo que hace y con que objetivos, se trata de elegir la herramienta que mejor implemente las practicas que quiero seguir. Mientras la gente insista en hacer las cosas al revés, elegir primero una herramienta y luego adaptar sus prácticas a lo que permita la herramienta, pues mal asunto, luego nos quejamos de la herramienta porque no hace milagros.
#17 Mercurial tiene prácticamente lo mismo. Just sayin', por si alguna vez te obligan a gastarlo. Que yo también prefiero Git, pero Mercurial siempre está ahí.
#7 Precisamente una de las grandes ventajas de git es que no impone nada, si te lias con ciertas cosas, no las uses y listo. No se, es como culpar a un coche de que el volante gira demasiado y te has estrellado contra un muro.
Decir que la gente usa git "porque mola" es simplemente no tener ni idea de lo que hablas. Hay mil ventajas objetivas frente a otros sistemas.
Yo uso git incluso para pequeños tests...para evitar el factor coñazo de "que mierda habre tocado que ahora no funciona", o porque hacer copias de mis proyectos es tan simple como subirlos a la cuenta gratuita que tengo en bitbucket.
#15 En realidad, si dices que "Subversion es mucho más sencillo", es porque no has necesitado nunca hacer otra cosa que no sea "svn diff" y "svn commit".
Y eso lo puedes hacer exactamente igual con Git. Git se complicará lo que tú quieras que se complique.
#37 El no dice que puede programarlo, el dice que puede usar uno mejor, a ver si ahora para criticar una herramienta hay que saber programar una mejor, no digas chorradas hombre.
#39 Yo me acostumbre tantisimo a que me haga un stash automaticamente cuando cambio de rama y me lo vuelva a recuperar cuando vuelvo que interiorize esa feature como propia de git y ahora me cuesta pasar a otros GUI mas potentes.
#56 llamar puta mierda a algo no es una crítica muy constructiva que se diga, mas bien suena a desprestigiar el trabajo de un grupo de personas que habrán intentado hacer una herramienta, que muchos hemos usado por años. Podrás decir que es mejor o peor y dar motivos, pero llamar puta mierda a algo, no aporta nada.
Con Git pasa como con Vim o con un lenguaje de programación mismo: no puedes esperar aprender a usarlo bien de un día para otro.
Se empieza usando lo básico y consultando los comandos, y poco a poco conforme trabajas con ellos vas ampliando tus conocimientos de la herramienta y aplicando nuevas cosas.
En mi caso me tiré meses trabajando sin entender un pijo de la mitad de las cosas, los rebases me sonaban a chino y de vez en cuando hacía alguna liada en local.
Tras numerosos desastres/guarradas por parte de algunos compañeros, un día un grupo de compis de curro nos pusimos a discutir, investigar y establecimos un workflow con rebases y squash de commits previo al mergeo de las ramas. Desde entonces hacíamos las cosas mucho mejor, y como lo usábamos a menudo entendíamos cómo funcionaba y mejoramos nuestros conocimientos de git.
Otros compis de curro se negaron a sumarse a "hacer las cosas bien" con git, y eran precisamente los que la liaban, lo que provocaba roces porque da un poco de asco intentar hacer las cosas bien y que el de al lado se pase por el forro de los cojones las guías de estilo porque no quiere dedicarle ni un día a actualizarse.
Al final los que mejoramos usando git hemos acabado en empresas donde el nivel es mucho más alto, y donde lo de usar bien git ni se discute. Los otros siguen en su mundo.
Y vamos, aún me quedan muchas cosas por controlar/entender, que de vez en cuando me veo en un "detached head" y cagándome en todo. Pero poco a poco, como hasta ahora.
Nosotros estamos trabajando en una asignatura de la universidad, un grupo de 26 personas sobre un mismo proyecto. Lo mejor es una GUI para ver el orden de las ramas y la relacion entre ellas y la consola para realizar cualquier operación.
La verdad, llevo un tiempo usando Git por mi cuenta o como mucho entre dos y ahora, trabajando entre tantos, es cuando estoy empezando a aprender a usarlo.
Estoy aprendiendo a programar y me estoy dando cuenta de que necesito un sistema de control de versiones, ya la he cagado un par de veces por ir haciéndolo sin él. Dado que no soy informático, querría algo lo más simple posible para ir trabajando desde distintos ordenadores, ¿algún consejo de cuál debería usar?.
#53 Tener dos ramas de trabajo cuando tu proyecto supera los 20.000 archivos es muy trabajoso. El poder hacer "rebase" para resolver conflictos es comodísimo y reduce la cantidad de grandes merges. Por otro lado, es tremendamente lento al tener que interactuar continuamente con el servidor, lo que hace que la integración continua sea más lenta.
La lentitud a la hora de crear tags y ramas hace que sea mucho más complicado separar un proyecto grande en diferentes repositorios, que se referencien unos a otros y "apunten" a una versión concreta.
Y por otro lado, el no poder trabajar offline es un desastre. Y podría seguir... En cambio Git no tiene ninguna desventaja.
#7 Como usuario de SVN y luego Git, te digo que no recomiendo SVN no para una empresa pequeña. Cuando tienes más de un desarrollador trabajando sobre la misma base de código, siempre tendrás algún merge. Git soluciona los merges como los dioses, SVN no lo hace tan bien, de hecho, se lía muy fácilmente con los conflictos.
Otra ventaja de Git sobre SVN es que te permite trabajar y hacer commits "offline", la naturaleza distributiva de Git es un gran paso sobre los repos centralizados de SVN.
En resumen, no me cambiaría a SVN de nuevo en mi puta vida.
Se que no es nada 1337, pero la GUI de git-cola va genial para gestionar ramas de forma visual. En general es muy agradecido no tener que ir a google cada vez que necesitas un comando de los que usas de higos a brevas como los stash o los cherry pick.
#65 git. Para no complicarte y para empezar puedes ponerlo todo en una única rama (la master). Luego cuando vayas cogiendo soltura ya te meterás con otras características.
Utilizarlo es muy sencillo:
- git add path --> para añadir ficheros al repo
- git commit -am "descripcion de los cambios" --> para añadir todos los cambios al commit y escribir qué has cambiado
- git push --> para subir los cambios a la página donde almacenes el repo
- Si trabajas en equipo ya tienes que hacer un pull antes de cualquier commit. Básicamente por si alguien ha hecho un cambio desde la última vez que actualizaster tu copia local. Si no lo haces y ha habido algún cambio entonces el repo creará una nueva rama, que tendrás que unir a la máster con git merge
- Si quieres disfrutar de git sin tener que crear el repo en una página y bajártelo entones simplemente escribe git init en el directorio raíz y empieza a utilizarlo.
#71 entiendo que cuando se descalifica el trabajo de otras personas es porque uno cree que lo puede hacer mejor. También podría simplemente decir "vaya puta mierda de comentario"
No es que se insulte a mis antepasados, es que a veces se tiene la mala costumbre de descalificar/desprestigiar el trabajo de otros sin ningún motivo.
#75 Pues yo entiendo que es perfectamente legitimo criticar el trabajo de unas personas conociendo el de otras, sobre todo cuando hay datos objetivos como es el caso de SVN vs GIT, insisto, nadie tiene porque saber programar una herramienta para poder criticarla, basta con usar una mejor.
Pues no será por buena documentación sobre como usarlo, Git es de los proyectos con más documentación que he visto. Al principio cuesta un poco pero cuando le cojes el tranquillo te das cuenta de lo potente que es.
#68 lo de las ramas no te entiendo... con subversion haces un "copy" del directorio del proyecto y ya tienes una rama, y como el copy es un mero link, es inmediato. Los tags es igual: subversion no distingue entre rama y tag, todo son copias. stackoverflow.com/questions/25207108/cost-of-branching-svn-vs-git
El rebase en subversion es un mero update, ya que todo el mundo trabaja contra el mismo repositorio. Te pueden salir conflictos en aquellos ficheros que hayas tocado y no subido, como con el rebase de git, eso te pasa en cualquier sistema. De todas formas, donde no gusta encontrar conflictos, subversion permite hacer lock, cosa que en git creo que no puedes hacer. Eso ya va en gustos, he trabajado de las dos formas.
Lo del offline de acuerdo, pero en general eso no es un problema en la mayoría de las empresas porque la gente está en un ordenador de la oficina conectado al servidor de la oficina. Pero sí, es una ventaja de git, sin duda.
Yo he trabajado con los dos, y el 99% de las veces he funcionado igual con subversion. En cambio el rollo stage/unstage del git me cansa, la verdad.
#40 Lo que dice #48 más que te permite trabajar en remoto fácilmente (vía ssh) y casi no consume recursos. Si vas a usar una herramienta a diario tirar de consola puede ser mucho mejor; si solo la vas a usar de pascuas a ramos la UI es más fácil.
#7 subversión y Git son, a grandes rasgos, lo mismo. El problema no es el cvs que uses, sino la gestión de las ramas y en eso nos complicamos la vida nosotros, independientemente del sistema usado.
En realidad, muchas veces no es necesario hacer ramas. Otras, simplemente hay que mantener 2 o 3.
La locura viene cuando algún psicópata se lia a crear ramas como un loco.
Pienso que lo mejor de Git no es Git. Es Github. De hecho, Git no es "windows friendly". Fue concebido desde la línea de comandos y no creo que exista una interfaz que realmente exprima todo su potencial. Y muchos usuarios son reticentes a tener una ventana de comandos abierta. Sobre todo los usuarios que vienen del infame Windows.
#22 Depende de la cantidad de gente que utilice el mismo repositorio. Cuando varias personas hacen cambios, SVN se lía con mucha facilidad y entras de cabeza en el merge hell. Ahí ya dejas de verle la sencillez.
#81 Crear una nueva rama en subversion es fácil. Pero ahora trabaja un par de meses por separado en ambas ramas. Luego intenta unificarlas de nuevo en una única rama. Si has modificado los mismos ficheros a un lado y a otro, ya puedes llorar mientras esperas que subversion haga el merge bien.
Git resuelve ese tipo de cosas de manera mucho más transparente.
Y me dirás, ¿pero qué clase de engendro del mal haría algo así, separar ramas, modificarlas a lo loco y luego querer unificarlas otra vez? Te contesto: proyectos donde necesitas una rama estable a la que ir añadiendo sólo los cambios estables, pero que hay cambios que tardarás meses en poder terminar completamente y no quieres meterlo a "trocitos" para no romper la rama estable. O te dedicas perder el tiempo haciendo merges continuamente para que tu rama "inestable" esté actualizada o te dedicas a perder el tiempo haciendo un merge enorme al final.
Por no contar con la problemática de qué pasa si estás manteniendo versiones antiguas de un mismo software. En git, puedes meter una actualización de seguridad (por ejemplo) en la rama más antigua y pasarla limpiamente hacia "delante" hacia todas las versiones más modernas de forma transparente para ti en un solo comando. En subversion tienes que hacer parches, que podrán o no tener sentido en todas las ramas/versiones a las que lo quieres aplicar. Al final, acabas haciendo una y otra vez el mismo cambio a mano en cada versión.
Trabajar con subversion es como trabajar en una única rama de git. O sea: un dolor de cabeza si tienes equipos trabajando de forma simultánea en features diferentes pero sobre los mismos ficheros.
#50: Yo opté por TortoiseHg desde que ví el circo que es Git.
Mi tiempo lo pierdo en cosas productivas o improductivas, pero lo decido yo. Y si quiero hacer el tonto en la línea de comandos lo hago por voluntad no por sistema.
Que trollazo
He leído muchos tutoriales y o bien llego a la conclusión de que soy tonto por no entenderlo bien o liarse cuando se trabaja con varias ramas es algo normal
El problema viene cuando una empresa pequeña usa Git para un proyecto en el que trabajan un grupo reducido de programadores. Demasiado complejo. Lo suyo sería usar Subversion. Pero claro, "lo que mola" es Git.
Pues si no las necesitas, no las uses
El problema con las ramas es el que dice #8, que si las necesitas con svn sí que es una pesadilla.
pcottle.github.io/learnGitBranching/
Hay que pensar es que git organiza los commits en un gran árbol y las etiquetas y las ramas son simplemente apuntadores a un commit concreto.
Y sin miedo a romper nada, siempre puedes tirar de git reflow para reflog cuando la lías gorda para recuperar cosas.
Que trollazo
En todos saco las mismas conclusiones
Da igual lo poderosa que sea la herramienta, la estupidez humana la supera
Lo importante es s tener un juego de tests que todo el mundo pruebe antes de Git push.
Nuestra experiencia en el cambio de SVN a GIT en la oficina ha sido una reducción de casi la totalidad de incidencias de sistema de control de versiones.
Yo tengo un master resolviendo conflictos de mi compañeros y no soy asistente social
bazaar.canonical.com/en/
Y si te resulta muy complicado te quedas en la develop y ya está, que al final es lo que pasa cuando te pones a desarrollar y se te olvida crearte una rama, y tampoco nadie muere por ello.
El único problema que nos ha llegado a dar ha sido con proyectos web porque se nos líen los permisos de las carpetas del repo al automatizar procesos de la web y que se creen cosas con permisos del apache tal que al intentar hacer Pull no sea capaz de escribirlo en parte. Pero al final te pegas un poco y lo apañas.
Git no es difícil una vez entiendes la base, que tampoco es complicada.
Largo, pero muy educativo e ilustrativo.
Para el día a día, a mí este artículo me sirvió de ayuda: sergioviteri.com/2010/06/04/un-workflow-sencillo-con-git/
Y luego, siempre a mano: git-scm.com/book/en/v2
Luego, cuando uno tiene los conceptos claros y sabe lo que hace y con que objetivos, se trata de elegir la herramienta que mejor implemente las practicas que quiero seguir. Mientras la gente insista en hacer las cosas al revés, elegir primero una herramienta y luego adaptar sus prácticas a lo que permita la herramienta, pues mal asunto, luego nos quejamos de la herramienta porque no hace milagros.
Decir que la gente usa git "porque mola" es simplemente no tener ni idea de lo que hablas. Hay mil ventajas objetivas frente a otros sistemas.
Yo uso git incluso para pequeños tests...para evitar el factor coñazo de "que mierda habre tocado que ahora no funciona", o porque hacer copias de mis proyectos es tan simple como subirlos a la cuenta gratuita que tengo en bitbucket.
Y eso lo puedes hacer exactamente igual con Git. Git se complicará lo que tú quieras que se complique.
nvie.com/posts/a-successful-git-branching-model/
`mkdir proyecto`
`mkdir proyecto-12-10-2015`
`mkdir proyecto-13-10-2015`
`mkdir proyecto-24-10-2015`
`mkdir proyecto-2-11-2015`
`mkdir proyecto-20-10-2015`
`mkdir proyecto-final`
`mkdir proyecto-final-final`
`mkdir proyecto-final-final-final`
`mkdir proyecto-final-final-final-final`
`rm -rf proyecto*`
`mkdir proyecto`
Se empieza usando lo básico y consultando los comandos, y poco a poco conforme trabajas con ellos vas ampliando tus conocimientos de la herramienta y aplicando nuevas cosas.
En mi caso me tiré meses trabajando sin entender un pijo de la mitad de las cosas, los rebases me sonaban a chino y de vez en cuando hacía alguna liada en local.
Tras numerosos desastres/guarradas por parte de algunos compañeros, un día un grupo de compis de curro nos pusimos a discutir, investigar y establecimos un workflow con rebases y squash de commits previo al mergeo de las ramas. Desde entonces hacíamos las cosas mucho mejor, y como lo usábamos a menudo entendíamos cómo funcionaba y mejoramos nuestros conocimientos de git.
Otros compis de curro se negaron a sumarse a "hacer las cosas bien" con git, y eran precisamente los que la liaban, lo que provocaba roces porque da un poco de asco intentar hacer las cosas bien y que el de al lado se pase por el forro de los cojones las guías de estilo porque no quiere dedicarle ni un día a actualizarse.
Al final los que mejoramos usando git hemos acabado en empresas donde el nivel es mucho más alto, y donde lo de usar bien git ni se discute. Los otros siguen en su mundo.
Y vamos, aún me quedan muchas cosas por controlar/entender, que de vez en cuando me veo en un "detached head" y cagándome en todo. Pero poco a poco, como hasta ahora.
mundogeek.net/archivos/2015/10/31/git-es-sencillo/
La verdad, llevo un tiempo usando Git por mi cuenta o como mucho entre dos y ahora, trabajando entre tantos, es cuando estoy empezando a aprender a usarlo.
La lentitud a la hora de crear tags y ramas hace que sea mucho más complicado separar un proyecto grande en diferentes repositorios, que se referencien unos a otros y "apunten" a una versión concreta.
Y por otro lado, el no poder trabajar offline es un desastre. Y podría seguir... En cambio Git no tiene ninguna desventaja.
youtu.be/TwU-3MvnrEE
Otra ventaja de Git sobre SVN es que te permite trabajar y hacer commits "offline", la naturaleza distributiva de Git es un gran paso sobre los repos centralizados de SVN.
En resumen, no me cambiaría a SVN de nuevo en mi puta vida.
Utilizarlo es muy sencillo:
- git add path --> para añadir ficheros al repo
- git commit -am "descripcion de los cambios" --> para añadir todos los cambios al commit y escribir qué has cambiado
- git push --> para subir los cambios a la página donde almacenes el repo
- Si trabajas en equipo ya tienes que hacer un pull antes de cualquier commit. Básicamente por si alguien ha hecho un cambio desde la última vez que actualizaster tu copia local. Si no lo haces y ha habido algún cambio entonces el repo creará una nueva rama, que tendrás que unir a la máster con git merge
- Si quieres disfrutar de git sin tener que crear el repo en una página y bajártelo entones simplemente escribe git init en el directorio raíz y empieza a utilizarlo.
No es que se insulte a mis antepasados, es que a veces se tiene la mala costumbre de descalificar/desprestigiar el trabajo de otros sin ningún motivo.
El rebase en subversion es un mero update, ya que todo el mundo trabaja contra el mismo repositorio. Te pueden salir conflictos en aquellos ficheros que hayas tocado y no subido, como con el rebase de git, eso te pasa en cualquier sistema. De todas formas, donde no gusta encontrar conflictos, subversion permite hacer lock, cosa que en git creo que no puedes hacer. Eso ya va en gustos, he trabajado de las dos formas.
Lo del offline de acuerdo, pero en general eso no es un problema en la mayoría de las empresas porque la gente está en un ordenador de la oficina conectado al servidor de la oficina. Pero sí, es una ventaja de git, sin duda.
Yo he trabajado con los dos, y el 99% de las veces he funcionado igual con subversion. En cambio el rollo stage/unstage del git me cansa, la verdad.
mkdir proyecto-N
ln -s proyecto-N release
LN está para algo. Para eso precisamente.
En realidad, muchas veces no es necesario hacer ramas. Otras, simplemente hay que mantener 2 o 3.
La locura viene cuando algún psicópata se lia a crear ramas como un loco.
Git resuelve ese tipo de cosas de manera mucho más transparente.
Y me dirás, ¿pero qué clase de engendro del mal haría algo así, separar ramas, modificarlas a lo loco y luego querer unificarlas otra vez? Te contesto: proyectos donde necesitas una rama estable a la que ir añadiendo sólo los cambios estables, pero que hay cambios que tardarás meses en poder terminar completamente y no quieres meterlo a "trocitos" para no romper la rama estable. O te dedicas perder el tiempo haciendo merges continuamente para que tu rama "inestable" esté actualizada o te dedicas a perder el tiempo haciendo un merge enorme al final.
Por no contar con la problemática de qué pasa si estás manteniendo versiones antiguas de un mismo software. En git, puedes meter una actualización de seguridad (por ejemplo) en la rama más antigua y pasarla limpiamente hacia "delante" hacia todas las versiones más modernas de forma transparente para ti en un solo comando. En subversion tienes que hacer parches, que podrán o no tener sentido en todas las ramas/versiones a las que lo quieres aplicar. Al final, acabas haciendo una y otra vez el mismo cambio a mano en cada versión.
Trabajar con subversion es como trabajar en una única rama de git. O sea: un dolor de cabeza si tienes equipos trabajando de forma simultánea en features diferentes pero sobre los mismos ficheros.
Aquí lo explican muy bien:
www.atlassian.com/git/tutorials/merging-vs-rebasing/
Mi tiempo lo pierdo en cosas productivas o improductivas, pero lo decido yo. Y si quiero hacer el tonto en la línea de comandos lo hago por voluntad no por sistema.