¿Hay alguna razón para NO usar git-masquerading-as-cvs como una actualización a cvs?

Estamos usando CVS para alnetworkingedor de 50 proyectos java que desarrollamos usando Eclipse, y construimos usando Hudson.

Ahora hemos llegado al punto en el que queremos migrar a algo mejor, y estoy considerando que usar git enmascarado como un server CVS podría ser exactamente lo que nos conviene en términos de curva de aprendizaje.

Tenemos pocas twigs pero de larga duración, preferiblemente en un subset de files (esencialmente nos gustaría tener una sucursal específica para el cliente donde podamos tener solo unos pocos files realmente modificados, pero agregar más files más adelante si es necesario, y las herramientas deben entender esto).

Somos solo unos pocos desarrolladores activos ubicados conjuntamente.

Usualmente trabajamos con un espacio de trabajo por proyecto principal con un pago completo de todos los proyectos necesarios para buildlo. No usamos Maven, y solo usamos ant para build con Hudson.

Entiendo que git-support-in-Eclipse ha sido adoptado como un proyecto de Eclipse real. Alguna experiencia con eso?

Lo más probable es que configure un server git local para hacer la evaluación. Agradecería consejos sobre qué search explícitamente, lo que podría ser problemático.


Editar:

No usamos $ Id $ o una expansión de palabras key similar (ya que esto induce cambios en los files fuente que no nos interesan conocer.


Por lo tanto, agradecería cualquier experiencia con git en escenarios similares a los nuestros 🙂


EDITAR 2009-10-25: La pregunta aún está abierta. Hemos decidido alejarnos de las twigs (demasiado dolor) y acceder a múltiples treees fuente: una twig pr. Esto elimina un gran punto de dolor con CVS, pero aún queremos ser capaces de desarrollar sin acceso a la networking al repository. Por lo tanto, git sigue siendo muy relevante, y aún me gustaría escuchar experiencias de las trincheras.

Solo un comentario:

CVS es un VCS centralizado, lo que significa que todos sus proyectos pueden caber dentro de un repository de CVS: puede consultar cualquier subparte.

Git es un DVCS, y en el mundo Distribuido, un repository = un "componente" (o "module" o "proyecto", …).
Puede usar submodules para agregar varios repositorys Git bajo un paraguas.
Si clonas un repository de Git, obtendrás todo el historial (a less que limites la profundidad de la clonación).

Entonces, la organización de sus proyectos será diferente con Git, y no estoy seguro si la visión de un server Git "similar a CVS" aún se aplicará.

De la página de manual de git-cvsserver :

DESCRIPCIÓN

Esta aplicación es una capa de emulación CVS para git.

Es altamente funcional. Sin embargo, no todos los methods están implementados , y para aquellos methods que se implementan, no todos los switches están implementados .

Las testings se han realizado utilizando el cliente CLI CVS y el complemento Eclipse CVS. La mayoría de la funcionalidad funciona bien con ambos clientes.

LIMITACIONES

Actualmente cvsserver funciona a través de conexiones SSH para clientes de lectura / escritura, y más de pserver para el acceso CVS anónimo 1 .

Los clientes de CVS no pueden labelr, bifurcar ni realizar fusiones de GIT.

git-cvsserver mapea twigs GIT a modules CVS. Esto es muy diferente de lo que la mayoría de los usuarios de CVS esperarían, ya que en CVS los modules generalmente representan uno o más directorys.

1. En realidad, el soporte para pserver no anónimo se envió recientemente a la list de correo git para su inclusión, y actualmente se encuentra en la twig 'pu' (actualizaciones propuestas), como "git-cvsimport: agregar soporte para cvs pserver password scrambling".