¿Una wiki integrada en un DVCS?

Question

Aquí vamos por el callejón subjetivo ..

Últimamente, he estado agregando un archivo llamado 'whiteboard.txt' en algunos de mis repositorios. Uso Mercurial, pero esto se aplica a cualquier DVCS. El propósito del archivo de texto es extraer formatos, flujo, ideas, etc. Dado que la mayoría de los sistemas de control de versiones distribuidas tienen algún tipo de interfaz web, ¿por qué no designar un directorio como 'wiki' y permitir que ser visto y utilizado como tal usando algo como Wiki Creole markup?

Obviamente, solo aquellos con acceso de confirmación podrían hacer cambios.

Mi punto es que, cuando el código esté listo para lanzarse, se realizará la wiki de diseño y un poco de documentación. ¿Por qué no integrar las dos herramientas colaborativas más importantes en una sola?

Por ejemplo, si pudiera:

hg --wiki y encontrar el razonamiento detrás de un grupo de 30 parches, así como su dirección prevista más allá de los comentarios abreviados en el registro de confirmación .. wow :) Cualquier cometer podía hacer referencia a una entrada wiki, además las discusiones se vuelven parte del repositorio y no un sitio secundario.

Si te gusta usar un DVCS porque puedes trabajar fuera de línea, ¿por qué esto no tiene sentido?

EDIT:

El punto de esto sería, si 'Joe' comete un archivo, debe ser capaz de establecer un atributo 'Nag' que impulsa a cualquier otra persona cambiando el archivo para actualizar una determinada página wiki , todo hecho fuera de línea con futuras fusiones resueltas detrás de escena. Después de todo, es texto, no código y se puede tratar como FIFO.

Si puede comprometer fuera de línea, también puede actualizar una wiki fuera de línea e impulsar sus cambios más tarde, incluso en formato de parche.

La idea es engañosamente simple.

Answer 1

quizá http://ikiwiki.info/

Un compilador wiki. Puede indicarle que almacene las fuentes wiki (archivos de texto de rebajas) en un repositorio (por ejemplo, git, mercurial, subversion). Las ediciones se pueden hacer a través de la web o copia de trabajo.

Answer 2

Buena idea, pero me gustaría mantener la wiki en un repositorio separado.

Algo así como Bitbucket.org do (cuando registra una rama, obtiene dos repositorios de hg, uno para la fuente y otro para la wiki).

Answer 3

tengo un par de sugerencias:

• GitHub tiene un wiki integrado (e.g.). Lo mismo ocurre con muchas otras soluciones alojadas de VCS, como Google Code.
• Trac es una wiki con enlaces VCS muy ajustados y un enfoque orientado al desarrollo.

Answer 4

Hay un proyecto llamado Fossil que hace exactamente esto. No lo he usado personalmente, pero está hecho por la misma persona que escribió SQLite, así que supongo que es pequeño y rápido.De hecho, según el sitio, todo se almacena dentro de una pequeña base de datos SQLite, por lo que debería ser fácil de archivar y transportar.

Answer 5

Véase también Hatta. He intentado sin éxito hacer que funcione, pero eso es solo porque soy pésimo con la configuración de Python.

Answer 6

Para anotar sus confirmaciones con información sobre lo que se hizo y por qué es en parte el motivo por el que utilizo un sistema de seguimiento de problemas como Trac. Un sitio de Trac (o entorno como lo llaman) se puede adjuntar con un control de versión. Puede consultar revisiones en el control de versiones con 'r', entradas con el signo '#' e incluso páginas wiki en Trac.

Ahora si combinara el código fuente y el seguimiento de problemas juntos, como Mylyn si es un desarrollador de Eclipse, en su IDE, entonces "magic" comenzará a suceder. He visto la forma de trabajar de Visual Studio Team System con el seguimiento de problemas y el control de versiones, pero debo decir que estoy más impresionado con la forma en que Mylyn maneja esto (dado que también puede funcionar con problemas sin conexión).

Answer 7

Pruebe jscreolewiki, funciona fuera de línea en un navegador, y es una buena idea almacenar contenido wiki en un DVCS.

http://jscreolewiki.googlecode.com/svn/trunk/jscreolewiki/index.html