svn + git + alternatives

[Gustavo Ringel]

Hi, en los ultimos tiempos he visto bastante movimiento de gente que trabajo siempre con cvs/svn hacia git y otras alternativas similares.

En un principio svn a nivel de trabajo me cubre todas las necesidades que tengo. Pero me gustaria entender que ventaja encontro la gente que se ha movido a Git o algo similar y porque tomaron la decision.

Lei cosas como commits y punto de retorno locales, merge mas rapido al trabajar en forma distribuida, que en mi caso no tienen demasiado peso...

Gustavo.

[José F. Romaniello]

Mira, yo lo estuve probando un tiempo. Mi opinión es que con GIT abre un nuevo abanico de posibilidades y eso es BUENO. Como commits locales, mantener tu branch localmente, y esas cosas que mencionaste.

Despues de haber probado un rato, me di cuenta que en mi trabajo actual no me hacía falta. Incluso en el grupo de 5 programadores que somos, rara vez iniciamos nuevas branch. Mi esquema actual es "dale para adelante", si alguien empieza a trabajar en una feature nueva que es grande, vemos como lo manejamos. Algunos pueden pensar que esto esta muy mal, pero hay que ser concientes que el hecho de mantener ramificaciones del repositorio es costoso, es costoso de mantener y es costoso a la hora de unificar. Si a eso le sumamos mantener ramificaciones por cualquier lado, en vez de preocuparnos en escribir código, vamos a tener que preocuparnos mas en administrar versiones.

Es una simple observación de por que en mi trabajo actual no me sirvió.

[Martín Salías]

Hola, Gustavo.

Nosotros estamos moviéndonos a GIT. Yo particularmente hice algunas cosas, y lo que me encanta es el concepto de trabajar completamente distribuido. Creo que GIT es fabuloso para equipos muy móviles, con gente conectada intermitentemente, viajando, etc.

Si tu equipo está físicamente en el mismo lugar y no trabaja desde otro lado que la misa oficina tal vez no te haga mucha diferencia sobre SVN.

Para proyectos OS es excelente porque no necesitas tener un repo central. Todos los repos de cada usuario tienen la misma importancia. Puedes usar uno como concentrador, pero puede ser diferente por partes de proyecto, etc.

Saludos,
---
Martín Salías
http://blog.Salias.com.ar

2009/11/15 Gustavo Ringel <gustavo...@gmail.com>

[mario.chavez]

Gustavo;

Hay muchas características que definen Git sobre otros sistemas de
control fuente, hay algunas que quizás para la mayoría no sean
importantes. Desde mi punto de vista las características que me
hicieron moverme de svn a git son:
- No se requiere servidor, ya que no existe un repositorio principal o
maestro.
- Un repositorio se puede compartir tan facil como copiar el
repositorio a otro disco o maquina o bien compartir la carpeta por la
red
- Los cambios en el repositorio se guardan como Deltas, por lo tanto
el tamaño de la historia es menor
- Todos los commit son locales y luego se pueden empujar a otros
repositorios

Espero que esta información te sirva, por cierto este screencast es
muy bueno para explicar git, aunque tiene costo de 9 USD
http://peepcode.com/products/git

Saludos

On Nov 15, 6:18 pm, Martín Salías <mar...@salias.com.ar> wrote:
> Hola, Gustavo.
>
> Nosotros estamos moviéndonos a GIT. Yo particularmente hice algunas cosas, y
> lo que me encanta es el concepto de trabajar completamente distribuido. Creo
> que GIT es fabuloso para equipos muy móviles, con gente conectada
> intermitentemente, viajando, etc.
>
> Si tu equipo está físicamente en el mismo lugar y no trabaja desde otro lado
> que la misa oficina tal vez no te haga mucha diferencia sobre SVN.
>
> Para proyectos OS es excelente porque no necesitas tener un repo central.
> Todos los repos de cada usuario tienen la misma importancia. Puedes usar uno
> como concentrador, pero puede ser diferente por partes de proyecto, etc.
>
> Saludos,
> ---
> Martín Salíashttp://blog.Salias.com.ar
>

> 2009/11/15 Gustavo Ringel <gustavo.rin...@gmail.com>

[Cristian Prieto]

Disculpa Mario, pero en SVN los cambios son deltas, la diferencia es que en Git son delta de directorio (en Git se guarda referencia al contenido del directorio, no al contenido del archivo) mientras que en SVN son deltas de archivos... De hecho, Git se caracteriza por no tener deltas de los archivos y por lo tanto su historia es ligeramente más grande que en SVN o Hg.

Debido a esto el armar la historia de un archivo o directorio en Git es más rápido que en Hg o SVN (Hg es el contraparte de SVN) porque estos utilizan deltas en vez de hacer tracking del archivo. En SVN se utiliza un algoritmo bien sencillo

delta = anterior - actual
if delta > anterior
    guarda nuevo archivo referencia
else
    guarda delta

lo malo es que al hacer una revision de archivo es mucho más sencillo en git que en Hg o SVN
por ejemplo, si estas en la rev 100 y quieres ir a la 150 debes revisar y rearmar el directorio de la revision 150 a partir de todos los cambios registrados desde el 100 hasta el 150 (es como dar un playback), esto es un poco complicado y lleva su truco, mientras que en Git guardas directamente el contenido y la referencia del archivo, por lo que obtener el directorio 150 es simplemente ir a buscarlo.

Git fue diseñado para trabajar bajo el concepto de "circulos de confianza" un concepto bastante útil en proyectos de código abierto, pero no muy versátil en proyectos de tipo centralizado (como la mayoría que nuestras empresas llevan), en ese caso se podría usar un approach "híbrido", otro día les converso un poco más de eso, que estoy corto de tiempo :)

Saludos a todos!

2009/11/16 mario.chavez <mario....@gmail.com>

--
Cristian Prieto
Microsoft ASP.NET MVP
MCPD ASP.NET Web Development Applications 3.5
MCTS Workflow Foundation 3.5

[Fabio Maulo]

dice el capo....
http://martinfowler.com/bliki/FeatureBranch.html

[Cristian Prieto]

Me gusta esta parte:

"With a less disciplined team I would worry that a DVCS would nudge people towards long lived branches, while a centralized VCS and a reluctance to branch nudges them towards frequent mainline commits. Paul Hammant may be right: 'I wonder though, if a team should not be adept with trunk-based development before they move to distributed.'"

2009/11/16 Fabio Maulo <fabio...@gmail.com>

dice el capo...

[Carlos Peix]

Puedo decirles, por experiencia directa ayudando a algunos equipos con VCS y CI, que es muy, muy dificil transmitir EL CONJUNTO de practicas recomendadas.

Ya opte por no pedir commits frecuentes, ahora intento que, al menos, no se vayan a la casa sin realizar un commit. Hay tantas cosas atadas entre si que resulta un trabajo arduo.

Por ejemplo, no usar branches salvo que sea necesario, realizar commits frecuentes y con la minima unidad de cambio que "cierre", no mezclar en un commit dos cambios no relacionados, en caso de trabajar sobre un branch, de mantenimiento por ejemplo, realizar commits frequentes y realizar el merge al trunk "lo antes posible!!!".

En fin, no quiero ni pensar lo que seria con un DVCS. En definitiva KISS principle.

Saludos

----------------------------------
Carlos Peix

2009/11/17 Cristian Prieto <keme...@gmail.com>

[Germán Schuager]

Yo hace tiempo que estoy trabajando con Mercurial (tanto en proyectos individuales como en un equipo chico distribuído), y una de las principales ventajas que encontré es que es (o por lo menos se siente) mucho más rápido que Subversion para las operaciones más comunes (incluso comparado con un servidor en LAN o local): commit, movimiento entre revisiones, show history, etc.

2009/11/17 Carlos Peix <carlo...@gmail.com>

[mario.chavez]

Cristian;

Tienes toda la razon, SVN es quien guarda deltas de los cambios, Git
no lo hace de esa forma.

> 2009/11/16 mario.chavez <mario.cha...@gmail.com>