Separación de documentos y wikis controlados por versión (teóricos / de layout)

Este es un problema que he encontrado para un par de proyectos diferentes en los que estoy trabajando.

Dado que los proyectos aún están en desarrollo sigiloso, y el problema en sí es de mayor interés y agnóstico para ellos, voy a anonimizarlo, pero FWIW, trabajo principalmente con Ruby / Rails y MySQL.

Guión

Quiero tener un sistema para editar documentos que sea como un wiki, pero tiene estas características:

  • Comportamiento completo de tipo VCS
    • múltiples usuarios asynchronouss
    • tenedor y fusión
    • culpa y diff
    • control de versiones, confirmaciones y retrocesos
    • edición sin connection en copys de trabajo / repositorys locales
    • almacenamiento eficiente y robusto
      • podría estar en MySQL o en un repository independiente, pero no almacenar el text plano completo para cada documento
  • nivel de file fork, merge, etc habilidad
  • máxima transparencia para los usuarios (no son muy piratas informáticos)

No necesito repositorys descentralizados, ya que todas mis aplicaciones involucran serveres autorizados, pero tampoco me importa tenerlos.

A diferencia de una buena wiki, los documentos con los que estoy tratando son frecuentemente networkingundantes (con pequeños cambios arbitrarios) y tienen historias bastante complejas de edición e integración.

Soluciones existentes

El primer requisito es muy hábilmente llenado, por ejemplo, por GitWiki:

  • website
  • repo
  • demo en vivo

Desafortunadamente, Git (y todos los demás VCSs que conozco) solo tienen tenedores de nivel de repository; no permite forks de nivel de file.

¿Qué es una horquilla de nivel de file / documento de todos modos?

Supongamos que escribo un montón de cartas de recomendación para mucha gente y las tengo continuamente disponibles. (Un poco de un ejemplo artificial, pero tengan paciencia conmigo).

En realidad, lo que tengo son tres niveles de cambios:

  • una plantilla de carta de recomendación básica que se aplica a todos ellos
  • una carta más específica para una persona en particular
  • una carta completamente específica para una persona en particular para un trabajo en particular

Ahora supongamos que quiero cambiar mi información de contacto o que tengo información nueva sobre una persona en particular. Conceptualmente, esto debería ser tan simple como:

  1. edite la carta base
  2. (auto) fusionar eso en todas las letras que henetworkingan de él

Transclusion

Esto también podría considerarse como el uso del control de versiones para un sistema de transclusión más flexible / robusto, con la diferencia de que, a diferencia de este ejemplo simple, partes de otro documento podrían copyrse con ediciones arbitrarias .

Otro ejemplo simplificado podría ayudar a explicar este problema de transclusión.

Supongamos que nuestros "documentos" son publicaciones en un foro. Una cosa común es citar las publicaciones de otros en su totalidad.

La cita en sí es networkingundante, y en mi uso, es útil para mí saber quién citó quién / qué, etc.

Entonces, en el caso simple, lo que podemos hacer es que cuando alguien cita a otro, en su editor aparece algo como: [quote msg=1234 v=1]What's the best recipe for mince pie?[/quote] My mom always used to...

En la mayoría de los casos, el usuario simplemente lo dejará en blanco y agregará sus respuestas a continuación. A continuación, podemos hacer una simple transclusión, soltar el text networkingundante y replacelo por un puntero al post citado, con el beneficio de poder mostrar la IU para indicar que el text citado se ha editado desde que se citó, y para facilitar la transclusión. ver cualquiera de las versiones.

Un paso más complejo, el usuario lo editará para que sea un extracto, por ejemplo, [quote msg=1234 v=1]mince pie?[/quote] Parsnip! . Nuevamente podemos hacer solo un puntero, esta vez agregando un desplazamiento y una longitud para la transclusión, y una IU para expandir el extracto.

Sin embargo, nuestra transclusión se rompe si el usuario hace algo como: [quote msg=1234 v=1]What's the best recipe for stupid pie?[/quote] Fixed! lol [quote msg=1234 v=1]What's the best recipe for stupid pie?[/quote] Fixed! lol . Podemos manejar esto incluyendo todo el text "fijo" (en casos less estúpidos, esto podría ser, por ejemplo, un resumen útil o reformulación) junto con nuestro puntero. La IU puede cambiar a la versión "no corregida", resaltar automáticamente la diferencia,

Desafortunadamente, solo almacenar el nuevo text, en lugar de manejarlo como una revisión real, significa que abandonamos todo el tema de control de revisión, y en documentos más grandes (por ejemplo, un progtwig, capítulo de libro, etc.), esto es insuficiente.

Más complejidad

Un escenario más complejo podría include, por ejemplo:

  • "twigs de desarrollo" de algún documento particular (y por lo tanto sus dependientes) siendo editadas -y versionadas- en paralelo con la "twig de producción"
  • historias complejas de unir / fusionar (por ejemplo, un documento secundario se edita, expande a lo largo y luego se fusiona parcialmente con sus padres y hermanos en la medida en que sea relevante para ellos)
  • relaciones documentales no jerárquicas (por ej., bifurca mi plantilla de carta de recomendación y hace sus propios ajustes, luego fusiono algunos de los ajustes en el mío, mientras tanto, alguien más ha bifurcado el mío otra vez …)
  • etc.

Principalmente trato con documentos de text reales, pero creo que esto se puede aplicar igualmente al código.

Las preguntas:

  • ¿Algo ya hace esto o algo similar?
  • ¿Cuál sería una buena manera de diseñar un sistema así?
  • ¿Qué componentes serían buenos candidatos para usar? (como git y sinatra se usan en gitwiki)
  • ¿Hay algo que estoy pasando por alto?

Las ideas de Github son similares. Utiliza las ideas de git pretty directamente. Sin duda vale la pena mirar.

Creo que git es una buena base para esto. Las operaciones de fusión / bifurcación de nivel de file podrían implementarse encima. Es posible que desee echar un vistazo a mi tenedor git-wiki . Podría extenderse para sus propósitos.

Intereting Posts