Solo algunas reflexiones, no organizadas.
Si tus amigos ya están acostumbrados a gitting, Git es un SCM distribuido bueno y robusto, con excelentes servicios de hosting disponibles, como Github o Gitorious.
Sin embargo, los conceptos de Git no son fáciles de comprender. Fossil tiene conceptos similares, pero es probable que sea más fácil comenzar (sin área de ensayo, sin concepto de índice, revocando los cambios desde la última confirmación con revert, no reset o checkout, etc.). No hay una plétora de subcomandos con plethoras de opciones, la ayuda es concisa y clara. Si tienes miedo de que te pierdas, elige fósil. Por supuesto, esto también significa que con fósil no puedes hacer tantas cosas como con git (sin rebase por ejemplo, al menos no por el momento).
Para fósiles, hay few hosting online services available. Es tan fácil como lo es con Git configurar un servidor para ejecutar Fossil.
Además, con Fossil, el historial de un proyecto se almacena en un único archivo, por lo que me resulta muy fácil realizar una copia de seguridad de todos los proyectos: poner todos los repositorios en la misma carpeta y realizar una sola tarea de sincronización. Sin embargo, esto hace copias de seguridad incrementales totalmente inútiles.
Mientras que con git, trabajando en dos ramas en los mismos proyectos en diferentes carpetas significaría tener dos copias de toda la historia del proyecto y ramas en dos .git/objects directorios distintos que pueden ser redundantes y enorme, con Fossil el esquema de trabajo por defecto es tiene que tener un único repositorio y uno o más directorios de trabajo conectados a él. Quizás si el uso del disco es importante, esto importará.
Advertencia, el rastreador de errores fósiles (sistema de tickets en la jerga) y wiki son bastante rudimentarios (aunque funcionan bien).
Los clones de Git en la misma partición crearán, de manera predeterminada, enlaces duros. Por lo tanto, el único espacio que necesita es para el árbol de trabajo – knittl
@Benoit, tenga en cuenta que 'rsync' -ing Fossil repos es un enfoque algo ingenuo ya que no requiere actividad de escritura en ese archivo de base de datos al momento de realizar la copia de seguridad. El único enfoque robusto para realizar copias de seguridad "en línea" es usar 'sqlite3 dump ...' y realizar copias de seguridad de los archivos de volcado posteriormente. Y Git no es realmente tan difícil de respaldar: solo tienes que usar Git para realizar esta tarea. Además, si se necesita una solución de alto perfil, gitolite v3 implementa la replicación maestro/esclavo en los empujes. – kostix
@kostix: a la gente le gusta hacer copias de seguridad en bits por varias razones. Aunque no veo ninguna razón legítima para hacer una copia de seguridad de un repositorio fósil en bitwise y no hacer un volcado sqlite3, algunas personas se mostrarán reacias a hacerlo. Además, fósil tiene replicación, pero no replicará algunos datos (por lo general, los datos que 'friega fósil' eliminará). Si no es necesario hacer una copia de seguridad de esos datos, basta con aprovechar la replicación para hacer una copia de seguridad. – Benoit