Barrapunto

El único hilo de esta noticia que no habla de aspectos técnicos es el de la ortografía. Todos los demás hablan de aspectos técnicos así que no se a que viene tu queja. Y por cierto el mensaje al que respondes y que según tú es el más técnico de todos es el de alguien que no ha usado un SCV distribuido o que no lo ha entendido.

Además de eso esta noticia habla de los SCV distribuidos en general, no de Git aunque lo nombre. Si quieres saber las diferencias entre Git y Mercurial aquí tienes unas cuantas. [rockstarprogrammer.org]

En cuanto al mensaje al que respondes, los commits locales no están pensados para substituir los commits al repositorio central. Tu a un repositorio central no puedes ir haciendo commits cada pocos pasos que realices porque si te cargas algo molestas a todo el mundo. Hasta ahora lo que se hacía era desarrollar en tu PC sin hacer commits hasta que no estabas muy seguro de que no ibas a romper nada, ahora lo que se hace es ir haciendo commits locales de los que nadie se va a enterar.

Por lo demás en Git puedes hacer que se ejecute un script al hacer commit, merge o lo que sea. Puedes hacer que este script te haga un backup o lo que tu prefieras.

Búscate otra excusa porque esa no vale: un repositorio centralizado *bien* utilizado no rompe nada por culpa de un commit, porque un commit ha de tener un valor semántico, no un valor funcional. Jamás he visto ni el manual de RCS, ni en el de CVS, ni el de Subversion, ni en el de Clearcase, ni en el Perforce, ni siquiera en el de Visual SourceSafe que un commit tenga que ser funcionalmente válido ni que tenga que poder compilar.

¿Trabajas solo? Eso del valor semántico queda muy chulo, pero si trabajas con alguien más en ese repositorio a la gente no le va a hacer gracia que el código deje de compilar cada vez que tú haces commit. Por no hablar de que ramificar y luego hace merge no es precisamente indoloro en svn.

Ahora, si alguien se empeña en usar la herramienta como *no* está pensada para ser usada, es lógico que aparezcan problemas. Lógico: usas mal la herramienta y luego buscas la manera de "saltarte" esas malas prácticas.

Por lo menos ten la decencia de poner cuatro líneas explicando los errores de base que tengo y un poco por encima como se hacen las cosas bien. Soltar eso tal cual es irrebatible pero no es ningún argumento.

Por lo que nadie se entera de en qué andas(y el que menos, tu jefe de proyecto), si se estropea tu PC de desarrollo (del que normalmente no hay copias de seguridad estables porque no debería haber nada de interés en él) se pierde todo ese trabajo, si te vas de la empresa a mitad de proyecto no hay que siga con lo tuyo, etc.

Hablas de que hago las cosas mal, y luego me sueltas ésto. Repito que los commits locales no sustituyen los commits al repositorio central. Si tu jefe de proyecto no sabe en qué andas es que es un incompetente. Si se estropea tu PC de desarrollo vas a perder 1 hora de trabajo como mucho. Los commits locales los vas a hacer cada 10, 15 minutos, los commits al central cada hora, cada dos horas. Los unos no sustituyen a los otros.

Así que primero dices que utilizo mal los repositorios centralizados como svn, y luego haces una crítica a los distribuidos que demuestran que no los has entendido o que no los has querido entender. Si quieres continuamos discutiendo pero desarrolla más el motivo por el que estoy utilizando mal los SCV centralizados.