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

20

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

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

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

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

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

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

soft-question research-practice software writing Андраш Саламон
источник
3
Я не совсем понимаю вопрос. Например, в SVN различия, отображаемые для пользователя, генерируются клиентом, и это зависит от вашего клиента SVN (и его конфигурации), получаете ли вы разностные данные на основе слов или разностные строки. Компания, в которой находится ваш SVN-репозиторий, никак не влияет на это.
Юкка Суомела
2
@suresh Если вы редактируете (пишете) текстовые документы, часто бывает сложно отсканировать всю строку в diff, чтобы увидеть, что кто-то изменил одну запятую. Правильное поведение обычно состоит в том, чтобы показать минимальную единицу изменения. Или рассмотрите поведение, если кто-то не использует разрывы строк. Затем изменение одного слова приведет к тому, что весь абзац появится в diff, и вы сможете найти крошечное изменение.
Марк Рейтблатт
2
Я не использую жесткие разрывы строк для переноса строк. В моем латексном исходном коде физическая строка текста обычно представляет собой полный абзац текста. Редактор может обернуть его для отображения в зависимости от текущей ширины окна. Это сильно упрощает вещи; никогда не нужно беспокоиться о таких вещах, как, например, перефразирование абзаца или согласование «правильной» ширины строки с вашими соавторами. Однако вам понадобится инструмент сравнения на уровне слов, чтобы быстро увидеть изменения.
Юкка Суомела
2
@ Андрас Я хотел сказать, что системе VC нужно только восстановить две версии на стороне клиента, и неудивительно, что все системы VC могут это сделать. Затем вам понадобится трехсторонняя утилита слияния на уровне слов, но я не знаю ни одной. (Например, TortoiseMerge и kdiff3 оба основаны на строках.) Если у вас есть такая утилита, то подойдет любая система VC, которая позволяет вам указать внешнюю утилиту слияния. (Это включает svn, bzr, git, hg ...)
Maverick Woo
3
Один из источников путаницы заключается в том, что существует встроенный двоичный алгоритм сравнения (который работает на уровне отдельных байтов), который используется SVN при обмене данными между сервером и клиентом, а также внутри сервера для хранения репозитория. компактный. Это просто оптимизация; он невидим для пользователя, и тот же двоичный алгоритм сравнения может быть применен к любому типу файла. Все видимые для пользователя вещи (понятные человеку различия, слияние, разрешение конфликтов ...) происходят на стороне клиента.
Юкка Суомела

Ответы:

11

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

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

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

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

Дэви Лэндман
источник
Я подумаю над тем, чтобы сделать это для своих собственных документов. Кажется, это простой способ достижения большинства моих целей. Но не все заинтересованы в том, чтобы работать таким образом ...
Андрас Саламон,
2
Для тех, кто не решается работать таким образом, вы можете использовать TortoiseGit, если им не нравится командная строка git. Если речь идет о каждом предложении в новой части строки, а также при условии, что максимальная ширина текста не задана, это не так важно. (Я работал над некоторыми проектами без этого правила)
Дэви Лэндман,
В целом, я согласен, что Git - хороший выбор. Но почему отдельные файлы для (под) разделов могут уменьшить количество ручных слияний? Мне также интересно, как начало каждого предложения в новой строке помогает (иногда предложения смешиваются в процессе редактирования).
дд1
Что касается разделения файлов: в то время я не понимал точных деталей слияния git, так что это на самом деле не нужно, но все же рекомендуется по другим причинам. Предложение на новой строке очень важно, так как большинство инструментов вокруг git всегда показывают изменения строки, если вы затем используете другую стратегию, скажем, разрешите редактору делать разрывы строк, каждый раз, когда кто-то меняет 1 слово в абзаце, вам придется искать это произошло, а в случае автоматического слияния: никак.
Дэви Лэндман
4

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

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

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

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

М.С. Дусти
источник
2
К сожалению, «лучшие практики» в этих документах - это как раз те вещи, которые нельзя навязать сотрудникам.
Андрас Саламон
4

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

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

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

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

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

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

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

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

Полдень шелк
источник
4

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

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

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

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

Различия, окрашенные на уровне слов с помощью Gitk

JJD
источник
1

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


источник
2
Мне кажется, что Kaleidoscope - это просто инструмент различий на основе линий, который, кроме того, выделяет изменения внутри каждой строки. Это не замена для wdiff и друзей. Калейдоскоп создает нечитаемые различия, если вы, например, просто берете абзац текста и изменяете некоторые разрывы строк. Инструменты на основе Wdiff просто игнорируют изменения в переносах строк.
Юкка Суомела