Совместные инструменты для чайников / профессоров

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

Они понимают, что могут бесплатно открыть учетную запись Dropbox, поделиться паролем и синхронизировать версию документа на своем компьютере с версией Dropbox. Если два человека одновременно редактируют один и тот же раздел, они будут перезаписывать изменения друг друга.

Они также слышали, что системы контроля версий, такие как SVN и Git, имеют инструменты для объединения одновременных изменений, которые работают достаточно хорошо. Документация этих продуктов, однако, довольно трудна для чтения, и она больше сосредоточена на том, как отменить изменения и как управлять различными «ветвями», а не на основных потребностях соавторов, пишущих бумагу.

Есть ли простая пошаговая инструкция о том, как использовать систему контроля версий в этой настройке:

• центральное хранилище
• локальные копии
• «умное» слияние
• нет филиалов

?

Какую из стандартных систем контроля версий проще всего использовать? (Мы говорим здесь о профессорах теоретической информатики.)

Существуют ли еще более простые инструменты, которые синхронизируются только с умным слиянием, без контроля версий?

И наоборот, действительно ли люди, которые используют системы контроля версий для написания статьи с одним автором, действительно считают, что возможность неограниченного отмены стоит дополнительной сложности?

Прежде всего: если вы заинтересованы в совместном редактировании в реальном времени, попробуйте что-то вроде бычкового . Это позволяет буквально редактировать документ одновременно.

Что касается ревизионных систем, я знаком только с SVN. Это то, что вы делаете, после установки Subversion, конечно:

1. Получить кого-то, чтобы настроить вас хранилище и дать вам URL, имя пользователя и пароль
2. Перейдите туда, где вы хотите иметь свою локальную копию
3. В оболочке (командная строка?) Введите: svn co url://to.your/repository(извлечение). Теперь появляется новая папка с содержимым репозитория.

Вот и все. Теперь самые основные команды:

• Каждый раз, когда вы добавляете новый файл foo, введите:svn add foo
• Всякий раз, когда вы хотите удалить файл, введите: svn rm foo
• Всякий раз, когда вы внесли изменения, введите: svn ci(регистрация)
• Всякий раз, когда вы хотите получить самые новые вещи, введите: svn up(обновление)

Есть также команды для перемещения, копирования, ветвления, разрешения конфликтов, ... но если вы не пробуете забавные вещи, вы можете справиться с вышесказанным. Если что-то сломалось или кажется, сделайте резервную копию ваших изменений, удалите всю папку и извлеките все заново. Это для SVN, как перезагрузка для Windows.

Приложение: я вижу, вы, кажется, обеспокоены "умными слияниями". Я предполагаю, что вы имеете в виду объединение разных версий файла с предположением, что два человека добавили вещи в отдельные части статьи. Насколько я знаю, SVN будет рассматривать это как конфликт, и, вероятно, это правильно. Я не думаю, что есть общая процедура, которая гарантирует, что вы получите то, что хотите, после того, как два человека манипулировали одним и тем же источником. Существуют графические SVN-клиенты, которые визуализируют такие конфликты и помогают вам разрешать их; они в значительной степени различают зрителей, где вы можете выбрать, какую версию оставить для каждой конфликтующей строки). Это потребует работы, хотя.

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

Даже если вы сотрудничаете с помощью SVN, вы можете использовать GIT для своего собственного локального управления версиями (я делаю!).

Первое предупреждение : GIT очень мощный и для базового использования использовать его немного сложнее, чем SVN (например, один параметр должен быть добавлен в командной строке; два шага для центрального хранилища).

$\Delta$

Основные команды, если у вас уже есть хранилище

• Клонировать репозиторий: git clone <url>
• Обновите ваш локальный репозиторий: git pull <repo>или просто, git pullесли вы клонировали, как указано выше.
• Команда pull действительно выполняет и то git fetchи другое git merge. Первый «извлекает» данные с центрального сервера, а второй применяет объединение ваших файлов и файлов сервера.

Слияние происходит автоматически, если в некоторых файлах нет одновременных правок. Если слияние не удается, ваш рабочий каталог остается в «состоянии слияния», что означает, что вам нужно исправить конфликты, а затем вы должны зафиксировать объединенную копию. Если в ваших файлах все еще есть неуправляемые конфликты, то фиксация снова не будет выполнена, мусор не будет зафиксирован.

• Добавить новый файл , который будет совершено: git add <file name>.
• Зафиксируйте изменения в вашем локальном репозитории: git commit -am "<textmessages>"или, git commit -aесли вы хотите редактировать сообщения о фиксации.
• Перенесите изменения в вашем локальном хранилище в центральное хранилище.

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

Создать пользовательский локальный репозиторий

• Создание репозитория git initв любой понравившейся папке.
• Выполнено!

Создайте общедоступное репо (также частное, если вы платите наличными) с приятным графическим интерфейсом.

• Используйте GitHub

Создайте как можно больше частных / публичных репозиториев с разными группами пользователей, но без графического интерфейса.

• Запросите учетную запись SSH без пароля на доступном компьютере.
• Не беспокойтесь, поскольку аутентификация выполняется с помощью ключей SSH.
• Установите Gitosis в соответствии с этим руководством .
• Теперь вы можете администрировать свой собственный git-сервер, отредактировав один файл и поместив его в репозиторий!

Git не нужен центральный сервер : любая папка на вашем компьютере может быть использована в качестве хранилища, так что вы можете играть с Git и делать свои тесты в автономном режиме. Вы можете инициализировать один репозиторий и моделировать трех соавторов в трех других папках без отправки одного бита в сети. Это связано с тем, что любая клонированная копия репозитория является полнофункциональным репозиторием, который вы можете зафиксировать. Это хорошо, если вы хотите работать в полете между США, Китаем или Европой.

Документы Google ( https://docs.google.com ) предоставляют отличные инструменты для совместного создания документов (включая редактирование в режиме реального времени). Он хранит все онлайн для вас и хорошо интегрируется с вашей учетной записью Gmail. По умолчанию Google Docs не имеет совместимости с LaTeX, но вы можете включить его, перейдя сюда:

http://docs.latexlab.org/

Я не уверен, насколько хорошо это работает для отката, но я уверен, что есть функция для этого. Я слышал о некоторых людях, использующих плагин LaTeX Google Wave для разработки предварительных набросков для статей.

Я заставляю моих соавторов изучать Mercurial, и раньше я заставлял их изучать Subversion. Если вы поклонник Subversion, просто прочитайте это , это все правда.

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

Что действительно нужно, так это «Github для ученых». Что-то, что дает репозиторий, имеет контроль версий, совместное редактирование и т. Д. Угадайте, что, есть http://www.scribetex.com/ .

Вот новый совместный онлайн-редактор латексных программ под названием WriteLatex, который выглядит многообещающе, как универсальный магазин для многих научных потребностей / потребностей в письменной форме.

• работает на мобильном телефоне
• имеет предварительный просмотр в реальном времени
• легкий / приватный обмен
• находит латексные ошибки
• позволяет добавлять латексные библиотеки / стили
• облачное хранилище

Соавтор Джон Hammersley разместил объявление в ТКС себе мета здесь , и он реагирует на обратную связь (больше 5 голосов по объявлению и он появится на главной странице). похоже, что со временем он может стать ценным инструментом для сообщества tcs, и, возможно, авторы смогут реализовать некоторые популярные функции специально по запросу.

А как насчет простых систем, решений:

• Google Docs, Zoho Writer ... и другие инструменты для совместной работы.
• Dropbox обрабатывает ситуации, когда два человека пытаются зафиксировать изменения в одном файле. Второй коммитирующий получает его / ее файл переименованным (X.txt -> X.txt_blabla ...), и исходный файл (X.txt) обновляется до последней версии. Дополнительная информация: Справка Dropbox: «Что произойдет, если два человека изменят один и тот же файл?»

Это не подлежит сомнению, но иногда возникают ситуации, когда часть группы способна к простым решениям, таким как SVN, тогда как другая часть группы способна к распределенному управлению версиями, например GIT. В таких ситуациях сотрудничество возможно:

• git-svn - двунаправленная операция между хранилищем Subversion и git
• Git - Ускоренный курс SVN
• Эффективно используя Git с Subversion

Я недавно открыл сайт sharelatex.com и использовал его вместе со своим соавтором для соавтора статьи. Мне так понравилось, что мой текущий план - использовать его для всех моих проектов. Некоторые заметные особенности:

• TeXing в реальном времени в браузере (как Google Docs, но сделан для TeX, подсветка синтаксиса и все).

• Компиляция в браузере и просмотр PDF

• Поддерживает проекты с несколькими файлами

• Имеет функцию истории

• Синхронизируется с Dropbox (скоро выйдет публично, из его текущего бета-статуса). Таким образом, вы можете перенести сохранение резервных копий и т. Д. В Dropbox. В зависимости от того, как это сделано, это также должно позволить вам использовать sharelatex, даже если ваши соавторы не хотят этого, если они готовы использовать Dropbox для обмена файлами.

• Вы можете скачать / загрузить свой проект в любое время, поэтому вы не застряли с помощью sharelatex, если что-то пойдет не так, или вы передумали или что-то еще.

Единственный недостаток (но я думаю, что оно того стоит): хотя использование sharelatex бесплатное, некоторые его возможности - нет. В частности, чтобы использовать синхронизацию Dropbox (когда они ее выпустят), или если вы хотите, чтобы более 6 соавторов работали над одним проектом sharelatex, вы должны заплатить 8 долларов в месяц. или 80 долл. США в год [по состоянию на апрель 2013 года]. Как только они выпускают синхронизацию Dropbox, это кажется мне очень справедливой ценой.

[Отказ от ответственности: я не имею никаких отношений с sharelatex или его сотрудниками, за исключением того, что я использую их продукт.]

SVN - это инструмент, разработанный для этой цели. Я приложил бы усилия, чтобы изучить это. Это не сложнее, чем научиться использовать, скажем, латексный пакет attribute2e или один из латексных пакетов pdf для создания слайдов.

Сказав это, я использую CVS вместо SVN. В нашем учреждении лучшая поддержка со стороны администраторов CS (сервер SVN более управляемый пользователем). Кроме того, я ценю, что файлы базовой версии все еще там и доступны для редактирования, если что-то идет очень-очень неправильно.

Есть 2 недостатка по сравнению с SVN. Переименования файлов не так хороши, но я могу с этим смириться (выберите хорошее имя в первый раз). Вторая проблема заключается в том, что для доступа к хранилищу нужна локальная учетная запись CS. Поэтому доступ из другого учреждения возможен только в том случае, если учетная запись создана первой. Конечно, я не ожидаю, что это будет реальной проблемой где-либо; местный сотрудник отдела, вероятно, может спонсировать эту учетную запись.

Ограничение локального доступа связано с тем, что администраторы не хотят поддерживать pserver. (Труднее обеспечить и т. Д.)