Sistemas de control de fuente que permiten la ramificación parcial

Originalmente se trataba de una pregunta dirigida a git / bitbucket , pero después de encontrar que nuestros requisitos no pueden ser respaldados, estoy buscando alternativas.

Tenemos una base de código principal que tiene algunas bibliotecas 'confidenciales'. Necesitamos una forma de crear una bifurcación o una bifurcación con fines de investigación (para trabajadores fuera del sitio) que no contendrán los files confidenciales elegidos, pero para todos los demás files todavía habrá capacidad para empujar, extraer y ver todo el historial.

He podido lograr lo mismo en forzada / SourceDepot VCSs, sin embargo, quiero ver cuáles son nuestras otras opciones.

Una gran ventaja sería la posibilidad de migrar con el historial de bitbucket. Otra gran ventaja sería la capacidad de algunos (incluso personalizados) serveres de http para navegar por códigos / historial que tendrían cierta capacidad de integración con JIRA (como bitbucket / git).

Aquí hay un ejemplo de lo que quiero lograr:

Repo1(main): |-publicFolder |-file1 |-file2 |-privateFolder |-fileA |-fileB Repo2(investigation): |-publicFolder |-file1 |-file2 

EDITAR:

Parece que el escenario es alcanzable en mercurial combinando dos cosas: convertir extensión más la function de subrepos sugerida por Lazy Badger

la parte convertida necesitaría seguir filemap.txt:

 include publicFolder 

y siguiendo el command de conversión:

 hg convert --filemap filemap.txt path/to/local/Repo1 path/to/local/Repo2 

El siguiente paso es eliminar publicFolder de Repo1 y, finalmente, crear shell del subrepo fino sobre ambos repositorys (para poder tratarlos como un único repository si es necesario).

  • Externas en SVN
  • Submodules en Git
  • Subrepos en Mercurial

son iteraciones más o less notables y ampliamente conocidas para la tarea especificada (separación y agregación) (debe escribir, por qué está mal o fallar)

Perforce permite tener un espacio de trabajo, es decir, una copy de trabajo, configurado con files procedentes de múltiples depósitos.

A continuación, puede tener acceso diferente para los diferentes depósitos [0].

Consulte la configuration de depósito múltiple aquí: http://answers.perforce.com/articles/KB/2437

Necesitará un // depósito público donde todos tengan acceso y un // almacén restringido cuando algunas personas tengan acceso.

Luego, dependiendo del derecho, las personas podrían crear un espacio de trabajo con cualquiera

 //public/... //restricted/... 

o solo

 //public/... 

Otra gran ventaja sería la capacidad de algunos (incluso personalizados) serveres de http para navegar por códigos / historial que tendrían alguna capacidad de integración con JIRA (como bitbucket / git).

Perforce tiene algún tipo de interfaz web llamada P4Web. No lo he usado yo mismo y, por lo que he visto brevemente, parece un poco obsoleto y rápido. Google me dijo que ya no es compatible.

Por otro lado, una solución sucia que funcionará con cualquier SCM es comprometer los binarys de su biblioteca en el repository público. De esta forma, ofuscarás un poco el código fuente. (Eso todavía se puede desmontar en cierta medida).

[0] un depósito de Perforce es más o less equivalente a un repository en otro SCM.