Інструменти спільної роботи для муляжів / професорів


36

Припустимо, що співавтори двох або більше різних установ пишуть папір у латекс, і хотіли б зробити це краще, ніж повторно надсилати чернетки вперед і назад.

Вони розуміють, що можуть безкоштовно відкрити обліковий запис Drobox, поділитися паролем та синхронізувати версію паперу на своєму комп’ютері з версією, що знаходиться в dropbox. Якщо двоє людей одночасно редагують один і той же розділ, вони замінять зміни один одного.

Вони також чули, що системи керування версіями, такі як SVN та Git, мають інструменти для об'єднання паралельних змін, які працюють досить добре. Однак документацію цих продуктів досить важко читати, і вона більше орієнтована на те, як скасувати зміни та як керувати різними "гілками", а не на основних потребах співавторів, які пишуть документ.

Чи є проста покрокова інструкція щодо використання системи управління версіями в цій налаштуваннях:

  • центральне сховище
  • місцеві копії
  • "розумне" злиття
  • немає гілок

?

Зі стандартних систем управління версіями, яку з них найпростіше використовувати? (Ми тут говоримо професорів теоретичної інформатики.)

Чи є ще простіші інструменти, які синхронізуються лише з інтелектуальним злиттям, без контролю версій?

І навпаки, чи дійсно люди, які використовують системи управління версіями для написання одноавторного паперу, відчувають, що можливість необмеженого скасування стоїть на додатковій складності?


Дуже цікаве запитання.
Олександр Бондаренко

1
Справді. Поки що я не знайшов нічого кращого за SVN, але іноді буває трохи нудно змусити новачка правильно використовувати його. Я з нетерпінням чекаю відповідей, які надають зручніші для користувача рішення.
Ентоні Лабарре

2
Мені подобається і це питання! @Luca: Вас також може зацікавити контроль версій для співпраці (із різними рівнями слів)? .
MS Dousti

1
У деяких галузях CS звичайно писати документи (та слайди) як грамотні джерела. У цьому плані корисні такі інструменти, як lhs2tex ( people.cs.uu.nl/andres/lhs2tex ). Підсумок полягає в тому, що приклади вихідного коду в роботі є компільованими та перевіреними, а результати можуть навіть генеруватися автоматично. У таких випадках справжній dvcs здається єдиним здоровим, що можна зробити :-)
sclv

btw dropbox має рудиментарний контроль над версіями: ви можете повернутись до попередньої версії будь-якого файлу. але злиття доведеться мати вручну, що може бути обломкою. все ж, навіть із svn, я думаю, що все-таки гарна ідея передавати віртуальні жетони навколо? Що я зробив, це розділити файл латексу на інший файл для кожного розділу і просто використовувати папку "Впадання".
Сашо Ніколов

Відповіді:


12

По-перше: якщо ви зацікавлені в спільному редагуванні в реальному часі, спробуйте щось на кшталт хобі . Це дозволяє вам буквально редагувати документ одночасно.

Що стосується систем ревізії, я лише знайомий зі SVN. Це, що ви робите, встановивши підрив, звичайно:

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

Це все. Тепер основні команди:

  • Щоразу, коли ви додаєте новий файл foo, введіть:svn add foo
  • Щоразу, коли ви хочете видалити файл, введіть: svn rm foo
  • Щоразу, коли ви внесли зміни, введіть: svn ci(реєстрація)
  • Щоразу, коли ви хочете отримати найновіші речі, введіть: svn up(оновлення)

Існують також команди для переміщення, копіювання, розгалуження, вирішення конфліктів, ... але поки ви не спробуєте смішних речей, ви добре з вищезгаданим. Якщо щось зламається або здається, створіть резервну копію своїх змін, видаліть всю папку та огляньте все заново. Це для svn, як перезавантаження для Windows.

Додаток: Я бачу, що ви, мабуть, стурбовані "розумними злиттями". Я припускаю, що ви посилаєтесь на те, що різні версії файлу об'єднані з припущенням, що двоє людей додавали речі в роз'єднані частини паперу. Наскільки мені відомо, svn трактував це як конфлікт, і, мабуть, правильно. Я не думаю, що існує загальна процедура, яка забезпечує отримання бажаного після того, як двоє людей маніпулюють одним джерелом. Є графічні клієнти svn, які візуалізують подібні конфлікти та допомагають вирішити їх; вони в значній мірі різняться глядачами, якщо ви можете вибрати, яку версію зберегти для кожної суперечливої ​​лінії). Однак це вимагатиме роботи.


6
Крім того, ви повинні використовувати ToriseSVN для обробки всієї взаємодії зі SVN графічно; це робить все вітерцем.
Полудень Шовк

3
Я додам до цього, що замість того, щоб налаштувати власний SVN-сервер, рекомендую використовувати безкоштовний розміщений сервіс, наприклад unuddle.com . Це досить безболісно і приватно.
Ананд Кулкарні

2
спасибі, і дякую Ананду за пропозицію скасувати, саме цей 1-хвилинний підручник я шукав. Я спробував налаштувати сховище на розв’язування, зробив дві локальні копії на різних комп’ютерах, вніс непомітні редагування та реєстрацію, і він виконує розумні злиття, як каже Суреш. (Якщо два користувачі вносять непослідовні зміни, другий, щоб зареєструватися, отримує повідомлення про помилку; але якщо другий оновлюється, а потім перевіряється, оновлення робить інтелектуальне об'єднання локально, і при реєстрації додається інтелектуальне злиття центральне сховище.)
Лука Тревісан

1
про роботу Рафаеля: etherpad.org - ще один інструмент редагування в реальному часі. дуже перспективний ...
Алессандро Косентіно,

1
Я повинен сказати, що багато людей віддають перевагу git over svn, але я сам не маю досвіду з цим.
Рафаель

12

Я помічаю, що "малий" підручник для GIT ніхто не дає , тому я спробую це висвітлити. GIT швидше і перевершує SVN, але, можливо, вам легше отримати обліковий запис SVN на сервері у вашому університеті, оскільки SVN добре налаштований. Також, можливо, ваші співробітники знають, як ним користуватися.

Навіть якщо ви співпрацюєте за допомогою SVN, можливо, ви хочете використовувати GIT для власної локальної версії (я це роблю!).

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

Другий біт попередження : GIT має філософію вважати набір змін атомарними ( як їх називають), навіть якщо набір охоплює кілька файлів. Також у GIT ви маєте поняття локального сховища та центрального сховища. ДОБРО : Ви можете працювати в автономному режимі. БАД : Вам потрібно два кроки приєднатися до центрального сервера.Δ

Основні команди, припускаючи, що у вас вже є сховище

  • Клоніруйте сховище: 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

Створіть стільки приватних / публічних сховищ з різними групами користувачів, але без GUI.

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

Git не потребує центрального сервера : будь-яку папку на вашому комп'ютері можна використовувати як сховище, тож ви можете грати з git та робити свої тести в режимі офлайн. Ви можете ініціалізувати одне сховище та імітувати трьох співробітників у трьох інших папках, не надсилаючи жодного біта в мережу. Це тому, що будь-яка клонована копія сховища є повнофункціональним сховищем, до якого ви можете скористатися. Це добре, якщо ви хочете працювати на рейсі між США, Китаєм чи Європою.


1
Оскільки я написав свою відповідь вище, я теж віддав перевагу Git. Якщо вам подобається Github, але ви вагаєтесь віддати свою інтелектуальну власність компанії (та / або заплатити за цю пільгу), перегляньте Gitlab .
Рафаель,

8

Документи Google ( https://docs.google.com ) надають чудові інструменти для спільного створення документів (включаючи редагування в режимі реального часу). Він зберігає все в Інтернеті для вас і добре поєднується з вашим обліковим записом Gmail. Документи Google за замовчуванням не мають сумісності з LaTeX, але ви можете ввімкнути її, перейшовши сюди:

http://docs.latexlab.org/

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


Вибачте, але це, мабуть, як побудова прототипу вашого нового винаходу в лабораторії вашого конкурента. Я знаю, що інструменти Google є популярними, імовірно, через простоту використання та доступність, але я сумніваюся, що вони дуже часто є найкращим вибором. Створити гідне робоче середовище не надто важко, коли ви доклали трохи зусиль. Я вважаю, що це не повинно бути занадто великим демотиватором для людей, які проводять близько десяти років після школи, щоб отримати право на роботу.
Рафаель

4
Я не змагаюся з Google ... тому для мене просто здається, що використання найпростішого доступного інструменту, який, здається, є однією з вимог, про які ставила ОП. Тільки тому, що він не працює у вашому командному рядку, це не обов'язково робить його поганим інструментом. Якщо йому не вистачає потрібної функціональності, то це проект з відкритим кодом, і ви можете використовувати свій досвід, щоб додати його. Крім того, якщо ви використовуєте версію для розробки, ви навіть можете використовувати локальний компілятор LaTeX замість тієї на їх серверах.
Артем Казнатчеєв

Не зрозумійте мене неправильно, я не хлопець, єдиний у CLI. Мені дуже подобаються графічні редактори, наприклад (хоча мені не подобається WYSIWYG). Факт полягає в тому, що існують альтернативи, які не надає найбільший майстер даних на землі. Я використовував термін "конкурент", оскільки, afaik, Google проводить деякі дослідження в галузі інформатики, особливо ароматів машинного навчання.
Рафаель

7

Я змушую моїх співавторів вчитися Меркуріалу, і я використовував їх для того, щоб вони навчалися Субверсії. Якщо ви шанувальник Subversion, просто прочитайте це , це все правда.

Незалежно від того, якою системою ви користуєтесь, на сьогодні найважче - змусити іншу людину встановити програмне забезпечення та почати його використовувати. Skype - ідеальне рішення. Останні версії Skype дозволяють "обмін робочим столом", що дійсно допомагає, коли ви хочете провести свого співавтора через процедуру встановлення. І я використовував прямий обмін робочим столом у поєднанні зі Skype, щоб написати папір зі своїм співавтором. Це працює досить добре.

Що насправді потрібно - це "Github для вчених". Щось, що дає сховище, має керування версіями, спільне редагування тощо. Здогадайтесь, що є http://www.scribtex.com/ .


Зараз я використовую Github для написання опитування з співробітником. Це досить зручно, і я не відчуваю потреби в спільному редагуванні в Інтернеті, оскільки ми зазвичай працюємо в різних розділах.
Суреш Венкат

bitbucket дасть вам переваги github з певною приватністю. Я тестую це.
Джеремі

5

ось новий спільний онлайн-редактор латексу під назвою WriteLatex, який виглядає багатообіцяючим, як майже єдиний магазин для багатьох наукових письмових потреб / вимог.

  • працює на мобільному
  • має попередній попередній перегляд
  • легкий / приватний обмін
  • виявляє латексні помилки
  • дозволяє додавати в бібліотеки / стилі латексу
  • хмарне сховище

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


2

Що про прості системи та рішення:

Це не викликає сумнівів, але іноді трапляються ситуації, коли частина групи здатна до простих рішень, таких як SVN, а інша частина групи здатна до управління розподіленими версіями, наприклад, GIT. У таких ситуаціях можлива співпраця:


2

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

  • TeXing у веб-переглядачі в реальному часі (як Google Документи, але зроблено для TeX, підсвічування синтаксису та іншого).

  • Компіляція в браузері та перегляд PDF-файлів

  • Підтримує проекти з декількома файлами

  • Має функцію історії

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

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

Єдиний мінус (але я думаю, що він того вартий): хоча використання sharelatex є безкоштовним, деякі його функції не є. Зокрема, щоб використовувати синхронізацію Dropbox (коли вони випускають її) або якщо ви хочете, щоб більше ніж 6 співавторів працювали над тим же проектом sharelatex, вам доведеться платити 8 доларів на місяць. або $ 80 / рік [станом на квітень 2013]. Після випуску синхронізації Dropbox мені здається, що це дуже справедлива ціна.

[Відмова від відповідальності: Я не маю жодних стосунків з sharelatex або його працівниками, крім того, що я використовую їхній продукт.]


Зараз це відкритий код! (І, fwiw, є також writelatex, який схожий, але його можна використати для швидкої розваги без реєстрації.) Це сказав, що я не ставлю свою інтелектуальну власність у комерційну хмару (доки вона не буде опублікована).
Рафаель

-5

SVN - це інструмент, розроблений для цієї мети. Я б доклав зусиль, щоб це навчитися. Це не складніше, ніж навчитися використовувати, скажімо, пакунок Latex з алгоритмомm2e або один із пакетів файлів pdf-слайдів Latex.

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

У порівнянні зі SVN є 2 недоліки. Перейменування файлів не такі приємні, але я можу з цим жити (виберіть хороше ім’я вперше). Друга проблема полягає в тому, що для доступу до сховища потрібен локальний обліковий запис CS. Тому доступ до іншої установи можливий лише в тому випадку, якщо вперше створено обліковий запис. Звичайно, я не очікую, що це буде справжньою проблемою ніде; член місцевого відділу, можливо, може спонсорувати цей рахунок.

Локальне обмеження доступу пов’язане з тим, що адміністратори не хочуть підтримувати відвідувача. (Більш важко захистити тощо)


3
Незважаючи на те, що це насправді не стосується запиту про покрокову допомогу та через те, що більшість перелічених переваг та недоліків, схоже, локалізовані в домашній установі відповідача.
Девід Еппштейн
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.