martes, 25 de octubre de 2011

Visual Studio, SVN y conflictos.

Mi compañero Pedro ha comenzado una serie de post sobre desarrollo en Java. En sus primeras entregas ha comenzado por uno de los puntos básicos del desarrollo en equipo: el repositorio de código fuente (o sistema de control de versiones). Como bien indica, uno de los más utilizados actualmente es el Subversion (SVN). Este sistema se comporta muy bien con grandes equipos y al permitir trabajar de forma desconectada hace que sea unos de los sistemas más utilizados por los proyectos Open Source.

Conflictos en SVN
De todas formas, si se trabaja con Visual Studio, se deben tener ciertas precauciones, debido a la forma de gestionar los conflictos que tiene SVN. Se detecta un conflicto cuando dos o más programadores realizan cambios en las mismas líneas de un fichero a la vez. Para indicar los conflictos SVN modifica el fichero de trabajo, marcándolos de esta forma:
<<<<<<< fichero
    modificaciones del usuario
=======
    última versión subida al SVN
>>>>>>> revisión
Además añade tres ficheros:
  • fichero.ext.mine: la copia del fichero de trabajo que usaba el usuario antes de lanzar el update.
  • fichero.ext.rOLDREV: una copia de la versión del fichero antes de que el usuario comenzase a modificarlo.
  • fichero.ext.rNEWREV: una copia de la última versión del fichero en el momento de detectar el conflicto.
Visual Studio y SVN
Visual Studio utiliza ficheros índice que le indican con qué trabajar:
  • fichero.sln: define la solución, contiene todos los proyectos, sus rutas y el modo de acceder a ellos.
  • fichero.csproj o fichero.vbproj: De forma similar a los sln, los ficheros de proyecto (proyectos vb o c#) contienen una lista con todos los ficheros que utilizan (código fuente, referencias a librerías, ...)
Los conflictos con estos ficheros pueden producirse inconscientemente por parte de los programadores, ya que al añadir un proyecto a la solución, o un fichero a un proyecto, el Visual Studio modifica los sln y los proj. Estas modificaciones, si se producen en paralelo, seguramente provocarán conflictos en y el SVN marcará estos en los ficheros. Con estos ficheros marcados el Visual Studio no es capaz de leerlos, por lo tanto, desaparecerían los proyectos o incluso la solución, del explorador de proyectos (lo que provocaría un buen susto a más de uno).
Para solucionar este problema, tan solo hay que salir del entorno de desarrollo y resolver el conflicto, depués volver a cargar los proyectos o la solución que provocaba el error.

Soluciones
SVN es un sistema muy extendido. A pesar de sus problemillas con Visual Studio, muchos de los proyectos Open Source de .NET lo utilizan.
Una de las estrategias más utilizadas para evitar estos problemas es ignorar los cambios en los ficheros solución y de proyecto para que el SVN no gestione sus actualizaciones. Cada vez que se realice un update, se deben buscar los proyectos, ficheros y referencias añadidas para incluirlas de forma manual, para que únicamente el Visual Studio gestione los ficheros índice. Aunque esto no parezca la mejor solución es una de las más extendidas.
Si todos los miembros del equipo de desarrollo están en la misma oficina, podemos utilizar otra estrategia. Siempre que un desarrollador añada un fichero, este lo sube y avisa al resto del equipo para que actualicen, de esta forma no se producirán conflictos en los ficheros índice.

Conclusiones
El SVN es un buen sistema para trabajo en equipo, aunque no lo recomendaría para utilizar con el Visual Studio. Sobre todo en las fases iniciales de un proyecto, donde varias personas suben ficheros en paralelo. En proyectos de mantenimiento, donde el desarrollo principal ya se ha finalizado y las tareas más habituales son editar ficheros (no borrarlos o añadirlos) podría ser una solución aceptable.
Existen soluciones alternativas al SVN, tanto de pago (Team Foundation, Source Safe) como gratuitas (como Mercurial o Git). Microsoft parece que apuesta por Mercurial, al menos eso parece indicar el soporte a este sistema por parte de www.codeplex.com, el portal que aloja proyectos Open Souce que gestiona Microsoft.

1 comentario:

  1. Está bien saberlo, ¡menudo susto me pegaría yo con la desaparición de proyectos¡

    ResponderEliminar