Используете ли вы какое-либо программное обеспечение/методы контроля версий в качестве писателей? [закрыто]

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

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

(Рассказ 1, Рассказ 2, Рассказ 3, ...)

Это не обязательно вопрос о программах, но о программном обеспечении для контроля версий, используемом для написания/писателей, методах, трюках, ...

На самом деле это не связано, потому что я ищу решение/рабочий процесс, который писатели используют при написании.
Это очень помогает, если вы пишете обычный текст, а не формат текстового процессора. Я полагаю, что если у меня есть текст, я могу делать все, что захочу, позже.
Имейте в виду, что из-за того, как был сформирован Writers.se, он будет сильно предвзято относиться к программистам и другим людям, занимающимся программным обеспечением, которые сначала хотят писать.
Google Docs, например, ведет автоматическую историю изменений.
@DavidThornley: ключевое отличие заключается в двоичных файлах и файлах ascii. VCS могут обрабатывать двоичные файлы версий, но вы не получаете никаких приятных функций (таких как сравнение версий), которые вы получаете с файлами ascii. Существуют текстовые процессоры, которые хранят свои документы в виде файлов ascii, в частности, lyx (который хранит файлы в виде латекса).
Связанный: писатели.stackexchange.com/q/ 10440 /1993
Я знаю, что этот вопрос очень популярен, но это вопрос опроса, который не подходит для формата SE. Спрашивать , что следует учитывать при принятии решения об использовании контроля версий или какую систему контроля версий использовать для документации, было бы хорошо, но со всеми ответами, уже представленными здесь, я не вижу простого способа внести это редактирование. Я предлагаю проверить связанные вопросы, а затем задать новый вопрос, если есть что-то, что вы все еще хотите спросить. Спасибо.
Я рекомендую использовать редактор Typora и git. Typora — редактор разметки WYSIWYG.
Полунизкотехнологичный ответ, который я часто использую (и предлагаю своим студентам) — копии по электронной почте самому себе в конце каждого сеанса письма или перед большими изменениями — это твердые копии, доступные как в папке отправленных, так и в вашем альтернативном электронном письме. адрес. Он использует отметку времени из электронного письма в качестве «версии». Преимущество этого заключается в том, что в случае сбоя основного компьютера в сети доступна последняя версия.

Ответы (21)

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

Я использую для них Subversion , TortoiseSVN для Windows, а также использую Dropbox для резервного копирования моего репозитория.

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

Забавно, я использую то же самое. Хотя хостинг мудрый, я использую VisualSVN. Его легко настроить в Windows, его можно просматривать в браузере, и он готов к использованию в сети. В сочетании с TortoiseSVN вы можете писать в любом месте дома практически без настройки.
Разве Visual SVN не является плагином для Visual Studio?
Я думаю, что он имеет в виду VisualSVN Server, который представляет собой предварительно настроенный веб-сервер Apache с модулем SVN и приятным графическим интерфейсом MMC для управления им — это установка в два клика, которая работает с любым клиентом SVN, а не только с VisualSVN VS. Плагин.
Да, это точно так же, как я. Я использую unfuddle для своего хостинга, так что все мои WIP сохраняются вне сайта.
Я знаю, что я тупой, но вы говорите, что используете SVN для своей письменной работы, чтобы отслеживать изменения, сохранять последние новости и т. д.?
@johnny - да, я пишу свои главы в виде простого текстового файла (без форматирования), так что SVN творит здесь свое волшебство.
Я делаю то же самое, но использую SyncroSVN, потому что я в ужасе от интеграции с проводником, хотя он работает нормально. Я работал непосредственно в Dropbox, но обнаружил, что иногда, когда я это делаю, возникают блокировки общего доступа. Я либо ПРИОСТАНОВЛЯЮ Dropbox для своего рабочего сеанса, либо работаю вне Dropbox и копирую его. Я также использую SyncBack, чтобы планировать резервное копирование (в виде ZIP-файлов) моих рабочих файлов в папку Dropbox\Backup один или два раза в день.
Также - я хост с Wush.Net. Очень дешево и очень надежно. Вы можете подключить практически любой движок Diff с TortoiseSVN или подобным. Я использую Beyond Compare, так как он неплохо справляется с форматами файлов Word. UltraCompare тоже хорош.
@Axarydax: Где хранится ваш репо? кажется, что процесс резервного копирования был бы намного проще с распределенной системой контроля версий...
Это также работает, если программное обеспечение, которое вы используете для письма, сохраняет свой текст и данные во что-то близкое к обычному тексту. Например, yWriter использует XML для метаданных и обычный текст RTF для текста, что означает, что стандартное программное обеспечение для контроля версий работает с ним очень хорошо.
@Axarydax, как преобразовать их в mobi/pdf?

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

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

Но я предупреждаю вас, что слияние файлов недоступно или вряд ли будет возможно, когда вы используете какие-то текстовые процессоры (например, Word). Это проблема всех систем контроля версий.

Я должен отметить, что слияние на самом деле является ошибкой не «текстового процессора» как такового, а только существующих текстовых процессоров, которые не поддерживают (внешний) контроль версий каким-либо образом, в какой-либо форме (хм, интересно, если Word работает с TFS... не то чтобы я бы использовал или рекомендовал TFS для этого)
Единственный способ, который я нашел для получения значимого сравнения и слияния, - это написать текстовый источник самостоятельно, будь то какой-то вариант XML, HTML, LaTeX или что-то еще. Конечно, в современных инструментах (и даже в Word :-)) есть понятие экспорта в формате XML, но каждый экспорт будет отдельной вещью с переносом новой строки и прочим, поэтому, если вы переписали одно предложение, весь абзац, вероятно, будет отображаться как " здесь что-то изменилось", что не очень полезно. Я пишу весь свой исходный код в текстовом редакторе, который не пытается «украсить» или форматировать/экспортировать за меня, и я могу легко объединять и просматривать различия.
+1 для Mercurial, также новые .docxфайлы Word представляют собой XML, поэтому возможно слияние (я не знаю, я использую LaTeX).
Я также использую mercurial, это потрясающее программное обеспечение. Я нажимаю свое репо на копию на диске Google. Я также использую libreoffice и сохраняю в формате .fodt, который представляет собой плоский XML-файл, что позволяет Mercurial правильно выполнять магию различий. До этого я использовал HTML. Что касается Docx, если что-то не было изменено недавно, они по-прежнему являются сжатыми файлами и не могут быть легко различимы.

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

Я предпочитаю службу резервного копирования Rsync.net , потому что они надежны, имеют справедливую цену, поддерживают (и поощряют) вас шифровать свои данные, а не давать им ключи, и действительно заботятся о конфиденциальности своих пользователей.

Git отлично работает с Latex. В частности, git diff --word-diffкоманда позволяет увидеть изменения слово в слово. Недавно я использовал Git+Latex для групповой презентации, и это сработало очень хорошо.

Я использую историю изменений Google Docs.

лист регистраций изменений

Настоящие системы контроля версий, такие как SVN и GIT, слишком сложны, требуют знания командной строки и действительно предназначены для совместной работы команд, работающих с десятками разных файлов одновременно. Они избыточны для писателей.

Я использую Microsoft Word для письма, и каждый раз, когда я сохраняю документ, Google Cloud Connect загружает мою версию в Документы Google. Я получаю резервную копию и историю изменений бесплатно.

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

Они вряд ли «слишком сложны», получите что-то вроде TortoiseHG/SVN/Git, чтобы дать вам приятный графический интерфейс. Для меркуриала создайте репо, фиксируйте каждый раз, когда вы сохраняете. на самом деле не сложно в основах, а для чего-то более сложного, просто быстрый поиск в Google может дать вам команду, которую вам нужно сказать, вернуться к предыдущей версии.
Хотя я согласен с @EvilSpork в том, что Git работает хорошо, когда вы используете его просто, когда что-то идет не так (например, с конфликтующими файлами) или когда вы пытаетесь сотрудничать с кем-то еще (и вы хотите объединить их запрос на извлечение), вы получаете бросили в ад командной строки довольно быстро.

Flashbake — это интерфейс командной строки для репозитория git, у которого был некоторый потенциал, но я думаю, что он так и не стал популярным. Он работает в фоновом режиме и предназначен для записи данных об окружающей среде, а также погоды в вашем физическом местоположении и музыки, играющей на вашем компьютере в то время, когда вы пишете.

Это детище Кори Доктороу, и на самом деле оно задумывалось не как система контроля версий, а скорее как архивный инструмент, в котором будущие историки могли бы копаться, поскольку личные дневники и тому подобное больше не распространены.

Это интригующая идея, и было бы здорово, если бы что-то подобное стало стандартом для работающих писателей.

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

Конечно, любую DVCS можно легко скопировать. И я бы вообще не стал называть VCS со встроенным трекером проблем, вики и веб-сервером «легким весом».
Исполняемый файл Fossil представляет собой один файл размером 5 МБ, в котором есть все необходимое. Git составляет ~ 650 МБ и приближается к 6000 файлов и 725 папок. (Цифры для Windows). Репозиторий ископаемых также представляет собой один файл. Git тысячи, хотя и в одной папке, которую легко скопировать. Функции веб-интерфейса Fossil являются необязательными, но их так же легко использовать, как и GitHub, если они вам нужны. Это квалифицируется как легкий вес по всем параметрам, о которых я могу думать, по сравнению с другими вариантами в этой области.

Я использую Celtx в качестве основного инструмента для написания и имею подписку на их Celtx Studio, которая дает контроль над версиями.

Это не совсем здорово, потому что вы должны быть постоянно подключены к Интернету (нет «Работать локально и синхронизировать, когда у вас снова будет Интернет»), и это медленно, если вы добавляете в файл тонны графики / мультимедиа (потому что каждый раз, когда вы сохранить весь файл загружается), но он есть.

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

Я новичок в Celtx, и одной из первых вещей, которые я сделал, была попытка поставить файл проекта Celtx под контроль версий SVN. С ним обращались как с двоичным файлом, на что я не надеялся. Знаете ли вы, возможно ли иметь детальный контроль версий без необходимости платить за облачную подписку?
@JW Не совсем так. В какой-то момент я действительно начал писать свою собственную систему контроля версий для Celtx, но тем временем я переключился на Scrivener и не довел ее до конца.
Я просто смотрю на веб-сайт Scrivener сейчас. Кажется, у них хороший дух. Спасибо.

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

Не могли бы вы добавить сюда ссылку, чтобы люди могли быстро получить доступ к этому программному обеспечению.
@tylerharms Scrivener доступен на сайте Literatureandlatte.com
У меня Scrivener настроен на сохранение всех резервных копий, что не является значением по умолчанию.

Я писатель, а не кодер, и я начал с того же самого вопроса. Я начал использовать Git, и он отлично работает, хотя на его изучение определенно ушло некоторое время. Это круто, потому что Git популярен, есть GitHub и им увлекается множество людей.

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

Я все еще использую Git с тех пор, как начал с него, но я потратил слишком много времени на его изучение, и он не лучше, чем Mercurial. Если бы мне пришлось делать это снова, я бы использовал Mercurial с SourceTree от Atlassian для графического просмотра и проверки изменений в черновиках по мере их внесения.

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

Вы знаете, что Bitbucket от Atlassian также работает с git, не так ли? это то, что я использую
Да! Вот где у меня есть мои репозитории происхождения.

Я использую Apache Subversion (просто для Android и веб-разработки, не совсем для написания контента) — либо на собственном хостинге, либо на Beanstalk клиента, либо на частных учетных записях GitHub.

Просто хотел порекомендовать моих любимых клиентов; оба они коммерческие, но доступные и определенно стоят своих денег: Syntevo SmartSVN & SmartGit .

SmartGit частично поддерживает SVN, но только базовый набор команд. Недостатком может быть то, что текстовые файлы можно сравнивать только 1:1; на любых других файлах просто видно, что в них что-то изменилось.

С одним файлом на главу и некоторым скриптом, который объединяет главы в виде простого текста в один файл - возможно, с заголовками глав и номерами страниц.

Я бы не рекомендовал TortoiseSVN - но это, вероятно, просто личное дело - любой клиент VCS, который получил полную реализацию набора команд, должен справиться с этой задачей.

Я использую Subversion и Git как интерфейс к Subversion.

Использование контроля версий несколько раз спасало мою задницу. Я определенно рекомендую это.

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

Я все пишу в текстовых файлах, а не в Word, Pages, Scrivener или чем-то подобном. Контроль версий и простой текст идут рука об руку. Однако вы можете использовать нетекстовые форматы с контролем версий, если хотите.

Я использую Mercurial (см. ответ Даниэля для ссылки). Я пишу (немного, атм) в чисто текстовых файлах (с помощью моего верного Emacs ;-D), но в разработанном мной (и на данный момент плохо разработанном) «новом» формате. Таким образом, у меня есть чистый текст почти без (по крайней мере, в настоящее время) форматирования (что рекомендуется, согласно этому самому сайту ;-)), но я могу генерировать TeX (или другие форматы позже), когда это необходимо.

Если я пишу что-то в текстовом формате, таком как LaTeX или HTML, я обычно использую контроль версий. Например, когда я писал свою дипломную работу (в LaTeX), я использовал Mercurial.

Для материала, написанного в текстовом процессоре, я обычно этого не делаю. Я сохраняю резервные копии (используя программное обеспечение Apple Time Machine), поэтому я могу вернуться в прошлое в любой день. И если я начну еще один черновик или основную редакцию, я вручную сделаю копию. Для незначительных изменений я буду использовать функцию отслеживания изменений моего программного обеспечения для обработки текстов.

Я использовал CVS, SVN, mercurial и git. Все работает просто отлично (ну, может быть, не CVS), но у Git есть одна особенность, которая особенно удобна — концепция промежуточной области.

Если вы работаете над чем-то более продолжительным, скажем, над романом, сцена действительно хороша. Скажем, вы вносите некоторые изменения в главу 1, а некоторые — в главу 7. С другими элементами управления версиями, если вы фиксируете свои изменения, это все одна фиксация. Это может быть хорошо для некоторых людей, но мне очень нравится возможность делать отдельные коммиты. Таким образом, если я хочу сохранить свои изменения в главе 1, но отменить изменения в главе 7, это легко сделать.

Вот краткий обзор: http://whygitisbetterthanx.com/#the-staging-area

В Mercurial есть Mercurial Queues , которые можно использовать, помимо прочего, в качестве промежуточной области.

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

В системе управления версиями вы можете выполнять такие действия, как diffs, чтобы в основном получить представление, показывающее изменения от одной версии к другой. Вы также можете создавать ветки, объединять ветки и так далее. В зависимости от того, где вы размещаете и что используете, у вас также могут быть комментарии в определенных строках (вплоть до обсуждения). Обычно это выходит за рамки управления версиями исходного кода и обычно в веб-просмотре.

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

Я лично рекомендую нечто подобное gitпо той простой причине, что в отличие от subversion вы можете работать полностью локально в любом месте и в любое время, т.е. если не очень понятно, без интернета или какого-либо сервера.

Само собой разумеется, что людям, как правило, трудно это объяснить (и те, которые мне приходилось объяснять, были не менее техническими). Это особенно верно, когда речь идет об инструментах командной строки, но графические интерфейсы не лучше. Одной из очень важных проблем является загрузка нежелательной почты, я предлагаю, если вы собираетесь использовать это как систему для совместной работы, обязательно установите несколько очень четких правил, поскольку ненужные нежелательные файлы в репозиториях приводят в бешенство.

У меня есть пара вещей, которые я сделал или пробовал за эти годы:

1.) Приступая к редактированию или записи на день, я делаю копию слова doc, используя дату в имени файла. Таким образом, у меня есть новая копия каждый день, и я могу довольно легко вернуться к предыдущей версии изо дня в день. Это похоже на то, от чего вы пытаетесь уйти, но это работает для меня.

2.) При выпуске в формате электронной книги я устанавливаю для каждого «выпуска» версию, аналогичную программному продукту (в дневное время я инженер-программист). «Выпуск» состоит из слова doc, pdf (для моего веб-сайта, Scribd и т. д.), ePub (для B&N), обложки png (для CreateSpace) и версии CreateSpace. Все эти файлы помещаются в отдельную папку. Бэкапы делаются в Carbonite.

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

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

Microsoft Word (и, по крайней мере, OpenOffice.org) поддерживает управление версиями — я точно не помню, как его использовать, но, по крайней мере, в более старых версиях кажется , что вы просто выбираете опцию «Версии» в меню файла.

Можно сравнивать разные версии с по сути симпатичной разницей, оставлять комментарии и т.д.

MS Word поддерживает управление версиями, но у него довольно неуклюжий пользовательский интерфейс, и все версии сохраняются прямо в одном файле .doc, поэтому ваш рассказ может иметь размер в мегабайты.
И сбой, потеряв всю свою работу. Не радостное событие.
Ну, поэтому вы часто сохраняете! При этом теперь я пишу все в vim и отслеживаю с помощью git. Но это не обязательно вещь для всех. :)

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

Я нахожу самую простую схему просто увеличивать главы. Например, гипотетическая глава 1 становится главой 1.2 с новой отредактированной версией. Таким образом, они самоорганизуются в алфавитном порядке в стеке папок и позволяют легко и четко прокручивать любую папку. Когда этот взгляд, а следовательно, и взгляд на то, что я делаю, сбивает меня с толку, я знаю, что история тоже; и найти, что удобный пневмоник.

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

Но, конечно, каждому свое! Удачи!

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

Плюсы использования контроля версий:

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

Я лично использую bazaar, но какой современный контроль версий вы используете, это скорее дело вкуса.

Связано (на тему «почему»): writers.stackexchange.com/q/10440/1993

Если вы используете Mac, многие упускают одну вещь: встроенную систему управления версиями, доступную в любом приложении, которое ее поддерживает.

Например, если вы пишете в Pages, вы можете выбрать «Файл» ▶ «Вернуть» ▶ «Просмотреть все версии», чтобы вернуться во времени к предыдущим версиям вашего документа. Это работает примерно так же, как Time Machine работает для всех файлов. И он доступен во многих различных встроенных и сторонних приложениях.

Конечно, вы также можете использовать Time Machine, чтобы вернуться в прошлое в папке, содержащей ваши главы или другие письменные документы.

Но это определенно работа, направленная на то, чтобы научиться писать в Markdown (что занимает целый час), и тогда это в основном делает вас программистом, и вы можете использовать инструменты программирования. Я пишу в BBEdit, потому что это дает мне ощущение длинной пустой страницы, а то, что я там делаю, может быть легко преобразовано машиной в любой формат для публикации. BBEdit поддерживает Git и Subversion.

Я использую The Novel Factory (как и следовало ожидать), которая позволяет мне иметь вкладки до трех черновиков, а также «блокировать». Я также иногда сохраняю новую версию всего файла своего романа на случай, если захочу вернуться к чему-то более раннему.

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

Возможно, это только я.