¿Hay algún sistema de control de revisión distribuido que admita el pago / clonación parcial?

Por lo que sé, todos los sistemas de control de versiones distribuidas requieren que clones todo el repository. Por esta razón, no es aconsejable colocar grandes cantidades de contenido en un único repository (gracias por esta respuesta ). Sé que esto no es un error sino una característica, pero me pregunto si este es un requisito para todos los sistemas de control de revisión distribuidos.

En rcs distribuidas, el historial de un file (o un fragment de contenido) es un gráfico acíclico dirigido, así que ¿por qué no puedes simplemente clonar este único DAG en lugar del set de todos los charts en el repository? Tal vez me pierdo algo, pero los siguientes casos de uso son difíciles de hacer:

  • clonar solo una parte de un repository
  • fusionar dos repositorys (preservando sus historias!)
  • copyr algunos files con su historial de un repository a otro

Si reutilizo partes del código de otras personas de múltiples proyectos, no puedo conservar su historial completo. Al less en git puedo pensar en una solución (bastante compleja):

  1. clonar un repository completo
  2. eliminar todo el contenido que no me interesa
  3. reescribe el historial para eliminar todo lo que no está en el maestro
  4. fusionar el repository restante en un repository existente

No sé si esto también es posible con Mercurial o Bazaar, pero al less no es nada fácil. Entonces, ¿hay algún rcs distribuido que admita el process de pago / clonación parcial por layout? Debe admitir un command simple para get un solo file con su historial de un repository y fusionarlo en otro. De esta forma, no necesitaría pensar en cómo estructurar su contenido en repositorys y submodules, pero podría dividir y fusionar repositorys según sea necesario (el extremo sería un repository para cada file).

A partir de la versión 2.0, no es posible crear un llamado "clon estrecho" con Mercurial, es decir, un clon donde solo recuperas datos para un subdirectory específico. Lo llamamos un "clon superficial" cuando solo recupera parte de la historia, por ejemplo, las últimas 100 revisiones.

Como dices, no hay nada en el model de historial basado en DAG común que excluya esta característica y hemos estado trabajando en ello. Peter Arrenbrecht, un queueborador de Mercurial, ha implementado dos enfoques diferentes para los clones estrechos, pero ninguno de los enfoques se ha fusionado todavía.

Por cierto, puede dividir un repository de Mercurial existente en partes donde cada repository más pequeño solo tiene el historial de un subdirectory específico del repository original. La extensión de conversión es la herramienta para esto. Sin embargo, cada uno de los repositorys más pequeños no estará relacionado con el repository más grande, la parte difícil es hacer que la split sea perfecta para que los sets de cambios mantengan sus identidades.

En rcs distribuidas, el historial de un file (o un fragment de contenido) es un gráfico acíclico dirigido, así que ¿por qué no puedes simplemente clonar este único DAG en lugar del set de todos los charts en el repository?

Al less en Git, el DAG que representa el historial del repository se aplica a todo el repository, no solo a un solo file. Cada object de compromiso apunta a un object "tree" que representa el estado completo del repository en ese momento.

Git 1.7 admite "loggings dispersos" , que le permiten restringir el tamaño de su copy de trabajo. Sin embargo, toda la información del repository aún está clonada.

Hay un module de subtree para git, que le permite dividir una parte de un repository en un nuevo repository y luego fusionar los cambios a / desde el original y el subtree. Aquí está su file léame en github: http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

En bazar puedes dividir y unir partes de un repository.

El command split le permite dividir un repository en múltiples repositorys. El command join permite fusionar repositorys. Ambos mantienen la historia.

Sin embargo, esto no es tan útil como el model SVN, donde puedes realizar un checkout / commit para un subtree.

Hay una característica planificada llamada Nested-Trees para bazar, que tal vez permitiría realizar pagos parciales.

Espero que uno de estos RCS agregue capacidad de clonación estrecha. Entiendo que la architecture de GIT (cambios / movimientos rastreados en todo el repository) hace que esto sea muy difícil.

Bazaar se enorgullece de soportar muchos types diferentes de flujos de trabajo. La falta de capacidad de clonación estrecha prohíbe un flujo de trabajo SVN / CVS en bzr / hg / git, por lo que espero que estén motivados para encontrar la manera de hacerlo.

Las nuevas características no deben ser a expensas de la funcionalidad básica, como la capacidad de search un solo file / directory desde el repository. La característica "distribuida" de los rcs modernos es "genial", pero en mi opinión desalienta las buenas prácticas de desarrollo (fusiones frecuentes / continuous integration). Estos nuevos RCS parecen carecer de una funcionalidad muy básica. Incluso SVN sin soporte de ramificación / labeldo real parecía un paso atrás de CVS imo.

De git help clone :

--depth <depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

¿Eso proporciona algo como lo que estás buscando?