Контроль версий для совместной работы (с помощью различий на уровне слов)?

Большинство работ в настоящее время написаны совместно, и сотрудники часто находятся в разных местах. Я всегда использовал системы контроля версий для своих документов и кода, а также обнаружил, что контроль версий важен для совместных программных проектов, но, похоже, многие исследователи в теории избегают их использования для написания совместных работ. Чтобы убедить моих сотрудников в том, что контроль версий (контроль версий) - это хорошая идея для совместной работы, существуют некоторые предпосылки. Невозможно заставить всех беспокоиться об определенном наборе условных обозначений для разрывов строк и абзацев или избежать преобразования табуляции / пробелов.

Предлагает ли кто-нибудь бесплатный хостинг небольших общих репозиториев документов с управлением версиями для текстовых документов, которое может обрабатывать различия на уровне слов ( не на основе строк)?

Если нет, то я бы приветствовал другие предложения, основанные на опыте (давайте избегать спекуляций, пожалуйста).

Я думал о Git, Subversion, Mercurial, darcs или Bazaar, настроенных для обработки различий на уровне слов с помощью wdiff, вместе с простым способом настройки доступа, защищенного открытыми ключами (например, через ssh). Однако ни один из провайдеров контроля версий, на которые я смотрел, не предлагает ничего подобного. Для научного сотрудничества «корпоративные» функции, которые подчеркивают многие из этих компаний, не очень важны (большое количество филиалов, интеграция с trac, аудит со стороны, сторонние команды проекта). Но различия на уровне слов кажутся критическими, но не поддерживаются. По моему опыту, при использовании различий на уровне строк для текстовых файлов каждый должен избегать переформатирования абзацев и редакторов, которые изменяют табуляции на пробелы или наоборот, вызывают проблемы; также, кажется, есть много ложных конфликтов редактирования.

См родственного вопрос в МО об инструментах для совместной работы , а также связанные с ними вопросы по поводу на TeX.SE, о системе управления версиями для LaTeX документов и LaTeX пакетов для контроля версий . См. Также сравнительную таблицу хостинга SVN для большого списка хостинг-провайдеров - только для одной из основных систем контроля версий.

Редактирование: ответ Юкки Суомелы на вопрос TeX.SE « Лучшие инструменты различий и слияний для Subversion с поддержкой LaTeX », по-видимому, пока является лучшим предложением, охватывающим, как интерпретировать дельты на уровне слова. Кроме того, Юкка объяснил, как различия между последовательными версиями на стороне хранилища отличаются от различий на уровне пользователя, используемых для обнаружения конфликтов и объединения изменений. Ответ Юкки на TeX.SE явно исключает одновременное редактирование и слияние, вместо этого полагаясь на традиционный атомарный токен редактирования, чтобы избежать конфликтов редактирования. Уточняя (и модифицируя) мой первоначальный вопрос, есть ли способ гарантировать, что конфликты редактирования могут быть разрешены на основе различий в словах, а не на основе различий строк? Другими словами, можетwdiffили аналогичные инструменты будут интегрированы в часть обнаружения конфликтов инструментов контроля версий, подобно тому, как можно игнорировать различия в конце строки и различия в пробелах?

Я использовал git для совместной работы над некоторыми документами, написанными на латексе. Вы должны будете придерживаться некоторых правил:

• Начинайте каждое предложение с новой строки, латекс игнорирует эти новые строки до тех пор, пока не будет пустой строки
• Используйте ту же конфигурацию для форматирования (табуляция / пробелы / максимальная ширина текста)
• Для достижения наилучших результатов создайте файл .gitattributes в своем хранилище и добавьте строку *.tex diff=tex. Это делает diff осведомленным о синтаксисе tex и приводит к более значимым выводам.

Затем вы можете использовать git diff --color-wordsи gitk --color-wordsдля просмотра различий в словах (см. Также эту статью Различения по словам в Git о том, как настроить git, чтобы всегда использовать алгоритм сравнения слов для отображения журнала git diff / git).

Чтобы уменьшить количество ручных слияний, я могу рекомендовать использовать отдельные файлы для разделов и подразделов (в зависимости от размера вашего документа).

Я предлагаю взглянуть на:

LaTeX / Совместное написание документов LaTeX ,

и соответствующий документ:

Инструменты для совместного написания научных документов LaTeX .

Я действительно хочу присоединиться к другим и предложить вам сесть и разработать хорошую стратегию SVN. Я использую SVN для размещения всей моей "исследовательской" структуры:

• JabRef справочный менеджмент
• Загруженные PDF-файлы
• статьи

Это здорово, потому что в нем есть все и, конечно, история. Предостережение в том, что вам нужен ваш собственный сервер. Но если у вас есть какой-либо существующий компьютер с Windows (или любой другой удобный для вас компьютер), вы можете установить его просто через VisualSVN Server . Затем вы создаете соответствующие учетные записи для соавторов и предоставляете им доступ к соответствующей области (т. Е. Возможно, к праву на чтение вашего файла JabRef bibtex и к чтению / записи в общей области статьи «в процессе»).

TortiseSVN может использоваться как клиент Windows для взаимодействия с SVN. Вы должны быть осторожны с перемещением / удалением файлов и копированием папок (SVN будет хранить метаданные внутри скрытых папок в каждой из ваших папок, поэтому вы должны выполнить команду удаления из SVN, чтобы избавиться от нее, требуется немного привыкнуть чтобы, но стоит вложений).

Затем, работая с коллаборатором, они также должны использовать SVN. Но, опять же, инвестиции в обучение не бесполезны. И если подумать, вы также можете получить его, чтобы у вас был доступ только для чтения к их файлу jabref (возможно, через 'external' средство в svn).

Таким образом, немного подумав и приложив немного усилий, вы можете оказаться в ситуации, когда вы редактируете документы в обычном режиме, вносите изменения ночью, обновляете утром и легко разрешаете все конфликты.

Я действительно рекомендую это. Чем больше людей создаст свои собственные SVN, тем лучше, так как это только улучшит возможности сотрудничества в будущем (хотя, конечно, было бы полезно, если бы существовал «стандартный» способ создания научного хранилища).

- Правка: Infact, я написал такое предложение здесь: Стратегия научного сотрудничества с LaTeX и SVN . Он предлагает использовать функцию svn externals, чтобы облегчить сотрудничество между людьми с похожей настройкой. Дайте мне знать, если это нужно изменить или просто не подходит.

Читая ваш замечательный пост и самостоятельно ища решение, я наткнулся на возможность раскрасить изменения на уровне слов в gitk . Параметр gitk представляется новой и / или недокументированной функцией, поскольку автозаполнение не предлагает его, а на странице руководства gitk его нет.
Вот варианты, которые я нашел:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Вы можете найти несколько обсуждений на эту тему в поиске "diff --color-words" gitk .

Редактировать:
это то, что выглядит как ...

Я очень хорошо понимаю проблему. Я начал использовать Kaleidoscope для сравнения с git. Он предназначен только для Mac, но его сравнение работает лучше, чем wdiff, а также имеет интерфейс и живые обновления.