Control de codigo fuente

[bnl]

Buenas
¿que utilizais para el control de versiones?
Yo en el trabajo utilizo TFS y source safe pero en mis proyectos personales no he utilizado ninguno.
Seria para utilizarlo para mis proyectos en Java para android utilizando el eclipse como IDE.

[jmtu]

Estoy probando a usar, sólo para conocer  lo del control de versiones y saber un poco de que va, Mercurial.
Lo instalé siguiendo esta guía :http://blog.freniche.com/2011/06/18/instalar-el-plugin-de-mercurial-en-eclipse/
   Ahí encontrarás este enlace http://hginit.com/ que explica como usar Mercurial desde la consola.

   La verdad es que no te puedo decir mucho más.
    Bueno, sí. La web del plugin: http://mercurial.selenic.com/wiki/MercurialEclipse

[Vicente]

Yo para mis proyectos personales siempre uso control de código fuente, normalmente Hg o GIT (con Tortoise HG o con SmartGit). En el trabajo es TFS o GIT. Normalmente los hosteo o en Codeplex o en Team Foundation Service, pero vamos, luego ya tienes mil sitios como GitHub o Bitbucket :)

En general creo que es útil acostumbrarse a un DCVS como Hg o GIT y a trabajar con "branch per feature" y similares (TFS o Subversion el tema de las ramas les mola menos :p).

Un saludo!

[julen26]

Yo hice un trabajo sobre el tema y después de hablar con gente entendida te puedo decir que GIT puede ser complicado. Pero el aprendizaje puede ser una inversión de tiempo ya que termina siendo de lo mas potente que hay. Por eso es apropiado para proyectos grandes, sin embargo puede ser inapropiado en proyectos pequeños. De todas formas si terminas manejándolo bien es toda una ventaja.

Por experiencia propia no te puedo decir mucho, ya que no lo usé durante mucho tiempo, pero me gustó la forma de trabajar en modo local y luego subir los cambios con un "push". Ademas el ser usado para mantener el kernel de linux le da cierto prestigio (notad la potencia que tiene para mantener semejante tamaño y cambios).

[cyberon]

Yo para mis proyectos utilizo visual SVN server, cierto es que lo utilizo para mí solo, pero por ejemplo, me sirve para tener el trabajo actualizdo en el sobremesa y el portátil. Lo tengo instalado en un disco duro propio del sobremesa para tenerlo separado del disco de trabajo, y va bastante bien.

http://www.visualsvn.com/server/

[Manu343726]

Tal y como ha dicho julen26, git puede ser complicado en un principio, pero a a larga es el más potente y flexible.
Esta es una buena web para aprender git: http://pcottle.github.io/learnGitBranching/
Es un tutorial interactivo que te enseña paso a paso las features de git. Personalmente siempre que voy a hacer algo raro con mis repos (Algún rebase extraño o algo por el estilo), siempre lo pruebo ahí primero (Tiene un modo libre) xD

Sobre clientes de git, creo que el más cómodo con diferencia es el cliente de github para windows: http://windows.github.com/

Para hacer cosas normalitas, véase commits, subir commits al repo, crear repos, clonar repos, gestionar ramas, etc tiene una interfaz gráfica muy sencilla y cómoda. Por supuesto siempre te deja abrir la consola. Offtopic: Este cliente es un buen ejemplo de lo que puede ser Metro cuando se hacen las cosas bien.

De todas maneras la mayoría de IDEs de hoy en día traen algún tipo de integración con git. En mi caso siempre uso netbeans para C++/Java, el cual trae git y mercurial integrados "de fábrica". Y las herramientas de diff que trae son sencillamente maravillosas:




Igualmente creo recordar que había un buen plugin de git para eclipse. Te pongo el cliente de github para eclipse, es muy cómodo: http://eclipse.github.com/ Si no usas github instala EGit directamente: http://www.eclipse.org/egit/

Espero que todo esto te sea útil

[[EX3]]

Me vais a permitir que le ponga chincheta al post para que no se pierda de vista, creo que puede ser de utilidad a mucha gente :)

Salu2...

[YaW]

Nosotros usabamos SVN antes y era una infierno, nos pasamos a Git y aunque al principio lloramos (mucho) ya nos hemos acostumbrado y la verdad es que se trabaja muy bien.

Eso si, hacerlo por linea de comandos todo me parece primitivo y el plugin que hay para eclipse es lamentable también. Lo mejor que hemos encontrado por ahora es el TortoiseGit.

[Manu343726]

Acabo de ver que han puesto una introducción al control de código fuente en los foros de discusión de codecademy.
Parece que está bastante bien. La pongo aquí por si a alguien le interesa: http://www.codecademy.com/groups/html-projects/discussions/5177d3a1758e99b46e003d6a

[sés]

Eso si, hacerlo por linea de comandos todo me parece primitivo y el plugin que hay para eclipse es lamentable también. Lo mejor que hemos encontrado por ahora es el TortoiseGit.

Prueba SourceTree. A mí me va genial.

[bnl]

Gracias a todos por los aportes

[bnl]

Estoy probando GIT.

Una de las cosas que he visto es que mueve en local el directorio que contiene el proyecto (que estaria dentro del workspace de eclipse) a la ruta donde este el repositorio local. Es una tonteria pero no me acaba de gustar. Estoy acostrumbrado al TFS que no te mueve los ficheros con los que trabajas.

¿Con Git trabajando una sola persona es necesario crear un branch por feature como se recomienda o bastaria con ir haciendo commits?

[TrOnTxU]

Con un branch te vale.

Pero comenzar a trastear con pruebas de branches y merges te puede venir bien (más que nada como pruebas, luego ya le puedes dar el uso que creas conveniente).

De todas formas en los DVCS (como Git o Hg) cada revision es como un snapshot/branch-tag de svn, o sea que puedes recuperar el estado total de todos los archivos recuperando esa revision (a diferencia de svn o cvs, que al llevar revisiones por archivo era un infierno recuperar el estado de la copia de trabajo de un dia concreto, por ejemplo), sin la necesidad de haber creado un "branch/tag" al viejo estilo VCS.

EDIT PS:
En cuanto a lo de la carpeta en el repositorio, es porque en los DVCS siempre tienes una copia del repo entero dentro de una carpeta de trabajo local (".git", ".hg", etc. dependiendo del sistema que uses).

Al principio, si vienes de trabajo con repositorios centralizados ralla un poco (a mi me pasaba al principio). Y tiene el incoveniente de ocupar más espacio (como es lógico).
Pero, la verdad es que te acostumbras, y creeme, al final vale la pena y mucho tener esa copia, y las diferentes maneras de ir juntando los branches o trabajando con otro repo centralizado en un servidor, o con el repo de otro usuario, aplicar parches, etc.

[bnl]

Lo mismo lo estoy configurando mal pero en las pruebas que he hecho mas que copiar lo que hace es mover todo el codigo fuente desde el workspace de eclipse donde estabas trabajando a otra ruta dentro del repositorio de git y luego ya no trabajas con los ficheros que tenias dentro del workspace de eclipse (que dejan de existir) si no con los que estan dentro de la carpeta del repositorio
Es una tonteria pero se me hace raro.

[TrOnTxU]

Lo mismo lo estoy configurando mal pero en las pruebas que he hecho mas que copiar lo que hace es mover todo el codigo fuente desde el workspace de eclipse donde estabas trabajando a otra ruta dentro del repositorio de git y luego ya no trabajas con los ficheros que tenias dentro del workspace de eclipse (que dejan de existir) si no con los que estan dentro de la carpeta del repositorio
Es una tonteria pero se me hace raro.

Igual no me explicado yo bien: el repositorio local y el workspace ESTAN DENTRO de la misma carpeta en Git (entre otros DVCS).
Los archivos del workspace estan colocados a partir de la raiz del directorio, y toda la informacion y copias de la versiones estan en un subdirectorio especial (".git") que hay en el raiz.

En la carpeta sobre que la que trabajes tendras todo, copia local y repositorio local.
Por lo tanto en eclipse lo que has de configurar es la ruta sobre la que quieras tener la copia de trabajo como repositorio.

Para "sincronizar" con otro repositorio (ya sea en otro disco duro o en remoto) debes hacer un PUSH. No basta con hacer un commit, ya que los commit en DVCS solo afectan al "repositorio local".

Como te digo es irte adaptando a la forma de trabajar de los sistemas de control de versiones distribuidos, intenta no partir de premisas demasiado rigidas de como deberia funcionar. Intenta aprender el nuevo workflow y poco a poco verás como es más útil.
Personalmente no conozco a nadie que después de trabajar en un proyecto entero con un DVCS quiera volver a los VCS. Las ventajas una vez "controlas" son muchas.