Pregunta

Actualmente estoy trabajando en un equipo en el que estamos "usando" Un repositorio de subversion. Digo " utilizando " ;, porque en realidad, todo el mundo solo está editando archivos directamente en un servidor a través de recursos compartidos de samba, mientras que de vez en cuando nuestro arquitecto realiza un compromiso de ese servidor con nuestros cambios, que luego se envían a los servidores.

Así que, básicamente, nos estamos perdiendo la posibilidad de tener mensajes de confirmación significativos de diferentes usuarios, y poder realizar la confirmación tantas veces como queramos.

He estado tratando de despertar cierto interés sobre los sistemas distribuidos, y cómo el flujo de trabajo que tenemos parece que podría configurarse muy bien con algo como git (nos comprometemos en nuestras máquinas locales y luego presionamos los conjuntos de cambios hacia él para revisión) pero no creo que tenga suficiente experiencia con git. La mayor parte de mi experiencia en DVCS ha sido con mercurial.

Todo el mundo está trabajando bastante en un entorno de Windows usando tortoisesvn, y esa es la forma en que están acostumbrados a interactuar con el sistema, pero ocasionalmente usan PuTTY para trabajar en uno de los servidores de Linux y saben cómo hacer una línea de comandos. cometer.

¿Cuál es el camino a seguir con esto? He visto que se está realizando un trabajo para crear puertas de enlace entre SVN y algunos DVCS. ¿Alguien tiene alguna experiencia en la configuración y el trabajo en un entorno así?

¿Qué hay de las migraciones a gran escala de SVN a un DVCS?

¿Fue útil?

Solución

Si su equipo no puede entender bien cómo usar Subversion, no sé cómo podrá hacer que entiendan git. Especialmente porque están en la mentalidad de " permite que todos trabajen en la misma copia de trabajo, " van a tener dificultades para comprender un sistema de control de versiones distribuido.

En mi experiencia, para usar svn-git, tienes que saber cómo usar git Y tienes que saber cómo usar svn. Recomiendo enseñarles a usar svn correctamente.

Otros consejos

¿Hay alguna razón por la que no quiera simplemente conservar su repositorio de SVN y utilizarlo de la forma en que se pretende que se use SVN?

¿Por qué no todos hacen que todos ingresen y se fusionen, usen sucursales, etc.? ¿Por qué cambiar si tienes una configuración de repositorio?

Parece que el problema que está describiendo tiene que ver principalmente con los procedimientos y protocolos adecuados para cometer código. obtener un producto diferente no cambiaría la forma en que las personas trabajan. primero debes educarlos. muéstreles cómo hacer las cosas mejor.

En una nota diferente, no entendí cómo usas tortoiceCVS para interactuar con SVN.

Para mí, parece que la elección de un sistema de control de versiones no es el problema. Lo que debe hacer es convencer al arquitecto de que debe elaborar algunas políticas sensatas para utilizar un sistema de control de revisiones.

Su sistema svn actual sería perfectamente adecuado; Permita que los usuarios creen sucursales si necesita mantener el tronco limpio. El arquitecto puede fusionarlos cuando lo necesite.

Ahora, usted podría mover un DVCS y existen buenas razones para hacerlo. Pero si el equipo no está acostumbrado a usar un cliente / servidor rcs, entonces esto puede ser un desafío. Y usted podría usar git o hg localmente, pero estas son soluciones para un uso de rcs fundamentalmente interrumpido. Hacer que todos usen svn primero sería mi sugerencia.

¿Editar archivos en un recurso compartido de samba? ¡¿Seriamente?!

git-svn es definitivamente su mejor apuesta aquí. Podrás usar todas las funciones de control de versión local y revisión de cambios de git, pero en última instancia puedes subir " final " registros en su repositorio svn existente.

Esto tiene el efecto secundario increíble de poder dejar que tu equipo se moje los pies con git un poco a la vez (tanto porque puedes probar antes de comprar como porque todavía puedes use cualquier proceso de implementación / mantenimiento existente que haya desarrollado utilizando SVN).

También hay un buen curso intensivo sobre la sintaxis de git para usuarios svn que puede usar para poner a su equipo al día.

Su problema no es SVN en sí mismo, pero no lo está utilizando correctamente.

Como Steve Yegge podría decir: TOOOOOLS

Como dicen otros, si no puede hacer que usen svn, no usarán una vcs distribuida.

¿Usan IDEs? Si es así, busque complementos para el IDE que faciliten el uso de svn. De modo que pueden hacer clic con el botón derecho en un archivo o carpeta en el IDE y registrarse. Si facilita el uso del control de código fuente en una copia local que el acceso directo a los archivos centrales, podría tener una oportunidad. Entonces puede usar TortoiseSVN para tareas más complejas.

Algunos enlaces a complementos SVN para IDEs populares para comenzar:

Y aquí hay una lista de complementos IDE del sitio web de Subversion.

hg también es bastante bueno trabajando con subversión; consulte https: // www. mercurial-scm.org/wiki/WorkingWithSubversion . El equipo de desarrollo central de Python decidió cambiar de Subversion a Mercurial (después de una larga discusión y período en el que también se consideraron git y bazar); en un desarrollo no relacionado, el servicio de alojamiento gratuito de code.google.com para proyectos de código abierto agregó soporte hg a su soporte de larga data para svn.

tanto git como bazar tienen buen soporte para svn. de hecho, git-svn ha madurado bastante en los últimos meses.

prueba git, porque un DVCS es realmente agradable y no es tan difícil como lo haces sonar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top