Intentaré darle algunas pistas respaldadas por mi experiencia personal.
Uno de mis compañeros de equipo, aunque experimentado, no entiende realmente SVN. Naturalmente, las áreas en blanco en su mapa mental que representan los océanos de SVN hacen que adopte patrones de uso bastante extraños.
Por ejemplo, había declarado una política de "1 confirmación SVN por día por desarrollador" porque de lo contrario "el servidor pronto se quedaría sin espacio en disco". Cuando le expliqué que los commits de SVN son deltas, no copias completas, respondió con dudas e incluso hoy no estoy completamente seguro de si entiende lo que significa.
Incluso si el espacio en el disco fuera un problema, siempre podría confirmar muchos archivos a la vez, por lo que creo que lo que sugiere es la solución incorrecta. Además, es posible desperdiciar mucho espacio al registrar archivos binarios grandes porque SVN no almacena deltas para archivos binarios. Un check-in por día también es malo porque te obliga a cometer cambios que no pertenecen, por ejemplo, en caso de que arregles más de un error por día.
La solución que hemos adoptado en nuestra empresa es que hay un filtro que rechaza cualquier confirmación que contenga archivos binarios. Podemos forzar la confirmación mediante el uso de una palabra clave especial en el comentario de check-in (tenemos que mostrar a SVN que sabemos lo que estamos haciendo). Una vez en un año o dos, un gerente de proyecto archiva las ramas antiguas y las elimina del repositorio. Con esta estrategia no tenemos problemas de espacio que conozco (nuestro repositorio admite varios proyectos diferentes y tiene más de 100000 revisiones).
En resumen, podría decirle que está de acuerdo con él en que el espacio en disco es un tema importante pero, por otro lado, señalar
- la importancia de los registros relacionados con funciones en lugar de un registro diario monolítico;
- el hecho de que al registrar un archivo binario grande por día, uno podría llenar el disco de todos modos.
Luego, podría sugerir que tenga una reunión (posiblemente también con otros desarrolladores o administradores del sistema) para discutir estrategias para mantener el uso del espacio en disco bajo control (por ejemplo, filtros de archivos binarios, copias de seguridad periódicas y limpieza de ramas viejas no utilizadas).
También tuvimos una acalorada discusión sobre si incluir la configuración del proyecto Eclipse en SVN. Mi compañero de equipo insistió en que deberíamos, aunque ha causado numerosos conflictos sin sentido. Estaba en contra de mantener archivos de configuración de desarrollador individuales en SVN. Finalmente, resultó que mi compañero de equipo tenía la práctica de volver a verificar todo el árbol de origen después de cada confirmación para asegurarse de que el "código comprometido en el repositorio funciona". Esa fue la razón por la que se mantuvo firme en mantener la configuración del proyecto en SVN, por lo que sería fácil volver a importar el proyecto. Cuando le expliqué que commit sincroniza la copia de trabajo a byte a byte remoto, lo que hace innecesario volver a realizar el pago, mi compañero de equipo respondió con dudas nuevamente y finalmente descartó todo el asunto como insignificante.
En mi opinión, nuestro equipo pierde tiempo resolviendo conflictos de SVN en los archivos de configuración del proyecto que contienen solo configuraciones específicas del desarrollador que no necesitan compartirse en absoluto con SCM. Todo este lío porque alguien ajustó el proceso en torno a suposiciones incorrectas.
¿Utiliza un servidor de compilación? Tenemos un servidor de compilación que revisa el proyecto completo y lo compila todas las noches. A la mañana siguiente, los probadores tienen un instalador listo para probar del producto (si la compilación maestra se ejecutó correctamente) y nosotros (los desarrolladores) tenemos un informe de compilación con todas las advertencias (y errores, en caso de que haya alguno). Por supuesto, es necesario configurar los archivos de configuración estándar para la construcción de servidor y comprobar a. Cada desarrollador puede comprobar a cabo junto con el resto del proyecto, pero no se le permite comprobar en cualquier cambios locales.
En este escenario, usted aborda su necesidad de poder verificar el proyecto completo y construirlo en cualquier momento. También evita perder tiempo para fusionar los cambios que no deberían haberse verificado en primer lugar porque no son parte del producto: el producto es la construcción maestra, y eso debe mantenerse limpio. Si alguien interrumpe la compilación maestra (por ejemplo, registrando su propio archivo .project), puede revertir los cambios u obligar a ese desarrollador a solucionar el problema.
Tal vez si vuelve a plantear el problema, puede volver a sugerirle una reunión (posiblemente con otros desarrolladores) y encontrar una estrategia común juntos.
¿Cómo puedo convencer a un compañero de equipo, que se ve a sí mismo como senior, para que comprenda mejor los conceptos básicos de SVN?
Creo que la mejor estrategia sería evitar llevar el conflicto a un nivel personal y más bien discutir los problemas en cuestión y las posibles soluciones. Si tiene la impresión de que está buscando una confrontación personal, aquí hay algunas sugerencias (de nuevo, por experiencia personal):
- ¿Cómo es la dinámica de tu equipo? ¿Sus otros colegas tienen una experiencia similar con este compañero de equipo? Hay muchos indicios pequeños, no demasiado explícitos, que un equipo puede dar a uno de sus miembros para desalentar ciertos comportamientos (pequeños chistes u observaciones) y alentar una confrontación constructiva (proponer una reunión o mencionar un tema informalmente durante un descanso para tomar café). ) A veces, un buen equipo puede aislar rápidamente un elemento perturbador y volver a la normalidad.
- ¿Qué tan buena es la gestión de su personal? Tuvimos un caso de conflicto en nuestra empresa y el jefe de personal tuvo que intervenir para aclarar la situación. No fue agradable, pero a veces el ambiente de trabajo se deteriora tanto que no mejorará por sí solo. Espero que este no sea su caso (no tengo la impresión de que haya llegado tan lejos todavía), pero siempre es bueno saber si tiene una buena administración de personal o si tiene que resolver los conflictos por su cuenta.
¿Por qué estoy escribiendo esto? Dices que quieres "convencer a un compañero de equipo, que se ve a sí mismo como senior, para que comprenda mejor los conceptos básicos de SVN". Para mí, parece que el conflicto podría ser demasiado personal. Algunos psicólogos sostienen que el 70% de nuestra comunicación es a nivel emocional, si este nivel no funciona, la gente deja de hablar sobre hechos porque están demasiado ocupados lidiando con las emociones.
Entonces, además de explicar sus puntos, también podría intentar hacer algo para mejorar la comunicación. Invitar a tomar un café o almorzar juntos, tener una breve conversación sobre un tema que no está relacionado con el trabajo, etc., puede mejorar la comunicación y atraer la atención de su colega a los hechos importantes que desea que comprenda. Si acepta este tipo de comunicación, entonces quizás los conflictos que tuvo hasta ahora estuvieron relacionados con el hecho de que no se conocen bien y hubo algunos pequeños malentendidos, pero probablemente esté abierto a construir una colaboración constructiva. Si se niega, entonces podría haber una hostilidad más profunda de su lado.
En este caso, creo que deberías esperar hasta que tus roles se aclaren. Si su compañero de equipo no tiene oficialmente un rango más alto que el suyo, no tiene sentido irritarse por sus intentos de mejorar las cosas. Con el tiempo, tendrá que aceptarlo o hacer el ridículo si sigue intentando demostrar que sabe más. Si tiene un rango más alto, debe encontrar una manera de hacerle entender que esto no está en discusión: sus observaciones están destinadas a mejorar la productividad y no a socavar su posición, esto debe ser 100% claro. Cuando los roles se han aclarado, si todavía no puede aceptar sugerencias constructivas o críticas, entonces realmente debe tener algún problema con la autoestima o algo así.
Entonces, si todas las estrategias anteriores fallan y sigues sintiéndote (muy) frustrado, me temo que lo único razonable es empacar tus cosas y buscar un lugar mejor. Hice esta experiencia hace tres años y encontré una compañía mucho mejor en la que estoy muy satisfecho ahora. Tal vez este no sea su caso (espero que no, por supuesto), pero trate de entender este punto también.
Solo mis 2 centavos.