Вики, встроенные в DVCS?

Question

Здесь мы спускаемся вниз по субъективному переулку ..

В последнее время я добавляю файл, называемый «whiteboard.txt» в некоторых из моих репозиториев. Я использую Mercurial, но это относится к любому DVCS.

Цель текстового файла состоит в хэш-форматах, потоках, идеях и т. Д. Учитывая, что большинство распределенных систем управления версиями имеют какой-то веб-интерфейс, почему бы не обозначить один каталог как «вики» и разрешить его просматривать и использовать как таковой, используя что-то вроде разметки Wiki Creole?

Очевидно, что только те, у кого есть доступ к фиксации, могут вносить изменения.

Я хочу сказать, что, когда код готов к выпуску, будет видоизменена викторина проекта и довольно подробная документация. Почему бы не интегрировать два наиболее важных инструментария совместной работы в один?

Например, если бы я мог:

рт.ст. --wiki и найти причины, лежащие в группе 30 пластырей, а также их предполагаемое направления за сокращенных комментарии в журнале фиксаций .. вау :) Любой мог совершить ссылайтесь на запись в вики, и дискуссии становятся частью репозитория, а не вторичным сайтом.

Если вам нравится использовать DVCS, потому что вы можете работать вне линии, почему это не имеет смысла?

EDIT:

Весь смысл этого было бы, если «Джо» совершает файл, он должен быть в состоянии установить атрибут «Наг», который выдает кто-либо изменения файла, чтобы обновить определенную вики страницу , все это сделано в то время, когда выходят из строя, и будущие слияния разрешаются за кулисами. В конце концов, это текст, а не код, и его можно рассматривать как FIFO.

Если вы можете отказаться от линии, вы также можете обновить вики-строку и направить свои изменения позже, даже в формате патча.

Идея обманчиво проста.

Answer 1

возможно http://ikiwiki.info/

вики компилятор. Вы можете поручить ему хранить источники вики (текстовые файлы разметки) в репозитории (например, git, mercurial, subversion). Редактирование может осуществляться через веб-интерфейс или рабочую копию.

Answer 2

Приятная идея, но я бы сохранил вики в отдельном хранилище.

Bitbucket.org do (при регистрации ветки вы получаете два hg-репозитория, один для источника и один для вики).

Answer 3

У меня есть несколько предложений:

• GitHub имеют встроенные вика (e.g.). Так делают и многие другие размещенные решения VCS, такие как Google Code.
• Trac - это вики с очень жесткими привязками VCS и ориентированным на развитие фокусом.

Answer 4

Существует проект под названием Fossil, который выполняет именно это. Я не использовал его лично, но это сделал тот же человек, который написал SQLite, поэтому я предполагаю, что он маленький и быстрый.Фактически, согласно сайту, все хранится в небольшой базе данных SQLite, поэтому его легко архивировать и переносить.

Answer 5

См. Также Hatta. Я безуспешно пытался заставить его работать, но это просто потому, что я отвратительно настроил Python.

Answer 6

Чтобы комментировать ваши данные о том, что было сделано, и почему отчасти это причина, почему я использую систему отслеживания проблем, такую ​​как Trac. Сайт Trac (или среда, по их названию) может быть прикреплен с помощью контроля версий. Вы можете ссылаться на изменения в управлении версиями на «r», на билеты с знаком «#» и даже на wiki-страницы в Trac.

Теперь, если вы собираетесь комбинировать исходный код и отслеживать отслеживание вместе, например, Mylyn, если вы являетесь разработчиком Eclipse, в свою среду IDE начинается "magic". Я видел способ работы Visual Studio Team System с отслеживанием проблем и контролем версий, но я должен сказать, что меня больше впечатляет то, как Mylyn справляется с этим (так как он также может работать с проблемами в автономном режиме).

Answer 7

Попробуйте jscreolewiki, он работает в автономном режиме в браузере, и это хорошая идея для хранения содержимого вики в DVCS.

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