VCS y el único "equipo" desarrollador

Soy un desarrollador individual que trabaja en un proyecto para mi empresa. Uso subversión y Trac (para el seguimiento de errores y la comunicación con types de gestión). Tengo un server intermedio y un server de producción. Hoy revisé un código y descubrí que mi repository svn (v1.4) basado en FSFS está irreparablemente dañado. Si bien esto es bastante fastidioso, me ha brindado la oportunidad de mover mi VCS / sistema de etapas a una distribución más moderna (actualmente en un sistema de 2 años de antigüedad). (En lo que respecta al repository, tengo una versión actual no corrompida del código, así que, aunque pierdo todo el historial y los comentarios del desarrollo, no pierdo ningún código.)

Actualmente desarrollo en Ubuntu y la producción funciona RHEL5-64. Mi hardware se mantendrá igual, un sistema de un solo núcleo x86 de 32 bits.

Estoy familiarizado con SVN y sus constructos, pero me siento un poco quemado por el problema de corrupción de FSFS. No sé mucho sobre git, excepto que es bastante popular. Actualmente uso Trac para gestionar problemas y realmente me gusta su integración con svn. Parece que hay complementos para habilitar el soporte para Git, pero no estoy seguro de la madurez de ese desarrollo.

Actualmente estoy pensando en build lo siguiente:

  1. Ubuntu 8.10 Desktop (y luego agregar apache2 y otros packages … la última vez que traté de agregar una GUI a la edición del server, me quité el pelo)
  2. SVN (porque estoy familiarizado con él y Git parece ser un poco exagerado para un equipo de una persona)
  3. Trac (porque estoy familiarizado con él y funciona con SVN).

Me gustaría recibir algunas sugerencias y reflexiones sobre mi "nuevo" sistema de vcs. ¿Hay alguna razón por la que deba mudarme a Git? ¿Hay algo "mejor" que Trac?

Git es un buen sistema de control de fuente, especialmente si estás contento con la línea de command. SVN es obviamente un buen caballo de batalla, y ahora está mucho mejor con el soporte de 1.5 fusiones.

Trac es bueno, pero cuando lo vimos, se limitaba a proyectos únicos y no era bueno en el departamento de soporte de control de código fuente.

Ahora utilizamos Redmine, que permite múltiples proyectos y nos permite utilizar diferentes types de control de código fuente para cada proyecto, incluido git.

Ah sí, y usamos Hudson para build 🙂

Yo uso git para todos mis proyectos personales. No puedo imaginar nada mejor para eso. Es especialmente útil una vez que el proyecto te supera. Su process de desarrollo debe cambiar casi en absoluto, excepto para agregar un empuje ocasional a un repository público.

SVN (porque estoy familiarizado con él y Git parece ser un poco exagerado para un equipo de una persona)

git es muy ligero y fácil de usar. La syntax es ligeramente diferente de la subversión, pero eso es todo. No diría que es excesivo. Realmente no hay nada al respecto que sea más o less complicado de usar que la subversión.

Para el seguimiento de errores utilizo un sistema basado en web llamado Pivotal. Es gratis (por ahora), y tiene algunas características de administración de proyectos integradas. Es ideal para equipos pequeños porque es muy simple, ya que no requiere casi ninguna configuration para su uso.

Usamos svn / trac / ubuntu aquí.

Para networkingucir el impacto de la corrupción, sugiero que implemente un trabajo automatizado (cron?) Para copyr los repositorys svn y trac una vez al día y enviarlos fuera del sitio (rsync) para realizar copys de security. Aquí usamos un NAS, pero algo como S3 o Dreamhost también funciona bien.

De esta forma, solo perderá un día de trabajo si algo sale mal.

SVN copy rápida:

svnadmin hotcopy $REPOSITORY $DESTINATION 

trac hotcopy:

 trac-admin $REPOSITORY hotcopy $DESTINATION 

Apoyo la recomendación para Redmine . Si bien soy primaramente un usuario de Mercurial, git también es compatible (como lo son Darcs, svn y cvs). Una de las cosas buenas de los sistemas de control de versiones distribuidas es que básicamente obtienes copys de security de forma gratuita (¿sabes que deberías haber hecho copys de security de tu antiguo svn repo, verdad?) …

Perforce es gratuito para hasta dos usuarios y tiene una buena reputación .

Voy a dar un paso atrás y tener una visión más amplia. Si está familiarizado y cómodo con SVN y Trac, y hacen el trabajo por usted (ignore por un segundo el problema de corrupción), cuestionaría la necesidad de mudarme. Este es el control de fuente y el seguimiento de fallas, y en general, siempre y cuando funcionen para su equipo, no veo que gastar un montón de esfuerzo en la gestión de su entorno, la installation y evaluación de nuevas herramientas, etc.

Mi recomendación de 10,000 pies sería usar esta oportunidad para ver la externalización de esta function por completo. Hay hosts (descargo de responsabilidad: mi empresa es una) que alojarán su Subversion, Git, Trac, Lighthouse, etc. por usted de forma gratuita o de bajo costo. Entonces, cuando algo va mal con la matriz de discos, o el FSFS o lo que sea, alguien que pasa el 100% de su time preocupándose por estas cosas puede manejarlo, probablemente sin siquiera darse count del problema. Si las políticas de su empresa le permiten utilizar un host para esta function, es posible que pueda save un fin de semana ahora, un fin de semana en el futuro (para la próxima catástrofe) e incontables dólares de su time productivo.