Разработка технической документации и технические писатели Технические писатели и разработка технической документации технические писатели в Телеграм 

 obmen_soobsheniyami.png Чат для технических писателей 
 Зарегистрируйтесь
Страницы: 1 2 След.
RSS
Общий доступ к документации, Общий доступ к документации с правом изменения файлов, но с сохранением предыдущей версии
 
Здравствуйте!
Интересует кто как организовал общий доступ к документации. Т.е. имеются несколько человек, которые вместе делают документацию. Необходимо, чтобы у каждого был доступ к правке, но сохранялся документ автоматически уже под именем <... Версия 2> и т.д., и в любой момент можно было вернуться к предыдущему варианту.
 
А в чем разрабатываете документацию?
techwriter.ru.com
 
techwriter, это еще выбирается)
Пока только word. Но проблема в том, что потом не получается найти конечного файла. Поэтому хотим "единую базу" какую-то сделать, чтобы все могли вносить свои правки, но при этом предыдущие версии не терялись.
Изменено: ПчОльkа - 28.08.2014 11:40:53
 
Цитата
ПчОльkа пишет:
techwriter , это еще выбирается)
Пока только word.
word не подходит для таких задач, смотрите на ПО, которое позволяет работать над документом нескольким пользователям : AuthorIT, Help&Manual (пиратскую версию найти легко) и т.д тогда это не составит больших проблем, плюс у вас появится возможность публиковать документацию в разных форматах
 
Почему же?
Word вполне подходит, если вместе с ним использовать какую-либо систему версионирования файлов (документов).
Например, http://tortoisesvn.net/
Если на предприятии используется какая-либо система документооборота, возможно в ней тоже есть версионирование.
 
Цитата
writer пишет:
Цитата
ПчОльkа пишет:
techwriter , это еще выбирается)
Пока только word.
word не подходит для таких задач, смотрите на ПО, которое позволяет работать над документом нескольким пользователям : AuthorIT, Help&Manual (пиратскую версию найти легко) и т.д тогда это не составит больших проблем, плюс у вас появится возможность публиковать документацию в разных форматах
Мы использовали Word+SVN. Но если идет процесс выбора, то согласна, лучше выбрать специализированный инструмент для технических писателей, в котором все это поддерживается.
techwriter.ru.com
 
Цитата
writer пишет:
word не подходит для таких задач
Подходит, если используется в SharePoint или OneDrive
Цитата
techwriter пишет:
Мы использовали Word+SVN.
Это не совсем то решение, если речь о файлах DOC. На самом деле SVN не работает с бинарными файлами, а Word создает как раз такие, если это не *.txt.
Вы использовали SVN просто как хранилище файлов с версией редакции файла, но не версией документа. SVN c недавних времен может только сравнивать некоторые файлы, но делать слияние не может.


Версионность документа можно делать как раз в MS SharePoint. Там возможна командная работа с бинарными файлами WORD, Excel и т.п. Ознакомиться можно тут  
 
Цитата
ADVANCED пишет:
Цитата
writer пишет:
word не подходит для таких задач
Подходит, если используется в SharePoint или OneDrive
Цитата
techwriter пишет:
Мы использовали Word+SVN.
Это не совсем то решение, если речь о файлах DOC. На самом деле SVN не работает с бинарными файлами, а Word создает как раз такие, если это не *.txt.
Вы использовали SVN просто как хранилище файлов с версией редакции файла, но не версией документа. SVN c недавних времен может только сравнивать некоторые файлы, но делать слияние не может.


Версионность документа можно делать как раз в MS SharePoint. Там возможна командная работа с бинарными файлами WORD, Excel и т.п. Ознакомиться можно тут
Не очень понятно, что имеется в виду под версией редакции файла. Есть документ, который хранится в едином хранилище. Он связан с документом, который находится на компе пользователя. При апдейте изменяется версия. Всегда можно вытащить содержание документа этой версии. Сравнить можно. По поводу слияния не знаю, не было необходимости пользоваться.
Изменено: techwriter - 28.08.2014 14:58:08
techwriter.ru.com
 
Вот про слияние в SVN: http://tortoisesvn.net/docs/release/TortoiseSVN_ru/tsvn-dug-merge.html
techwriter.ru.com
 
Цитата
ADVANCED пишет:
Версионность документа можно делать как раз в MS SharePoint. Там возможна командная работа с бинарными файлами WORD, Excel и т.п. Ознакомиться можно тут
Да все равно не очень удобно. Самое удобное, что было в моей практике - это RoboHelp.
У нас сейчас планируется переход на Doc-To-Help. Посмотрим, что он нам предложит.
techwriter.ru.com
 
А как насчет Google Docs? Там можно загружать, хранить и открывать доступ к файлам размером до гигабайта. Так же, можно загружать новые версии одного и того же файла.
 
Цитата
ПчОльkа пишет:
А как насчет Google Docs? Там можно загружать, хранить и открывать доступ к файлам размером до гигабайта. Так же, можно загружать новые версии одного и того же файла.
Использую иногда на некоторых фрилансерских проектах. Лично мне не очень удобно. Но ко всему можно приспособиться. Идеального варианта точно не существует. Надо выбирать то, что максимально подходит и под него адаптироваться.
techwriter.ru.com
 
И еще не понятно, с SVN можно или нет вести контроль версий файлов Docx (это же не бинарный файл)?
 
Цитата
ПчОльkа пишет:
И еще не понятно, с SVN можно или нет вести контроль версий файлов Docx (это же не бинарный файл)?
Считается, что можно, но могут возникать конфликты, которые могут привести к потере версий документов. Чтобы конфликты не возникали, надо всем, кто вносит правки договориться, как в нем работать и всем следовать этой договоренности. Тогда не будет проблем. Попробуйте еще потестировать на rtf. Думаю, с ним попроще.
Мне в связке с svn удалось добиться даже единого источника. Но все это не очень удобные варианты разработки документации. Они, скорее, идут от безысходности. Если есть возможность купить специализированное средство разработки, будет гораздо проще.
Изменено: techwriter - 28.08.2014 15:10:35
techwriter.ru.com
 
Наверное, и при слиянии могут возникать конфликты. Но я вот не понимаю, зачем их сливать с помощью SVN, если такая функция есть в Ворде :))) Если хочется сделать слияние, то просто надо выгрузить необходимые версии документов из SVN и выполнить слияние с помощью стандартной функции Word.
techwriter.ru.com
 
Еще вот это посмотрите: http://bazaar.canonical.com/en/
techwriter.ru.com
 
Цитата
techwriter пишет:
Не очень понятно, что имеется в виду под версией редакции файла. Есть документ, который хранится в едином хранилище. Он связан с документом, который находится на компе пользователя.
В хранилище SVN хранятся все версии редактирования файла. Т.е. отличия каждой версии от предыдущей. Сами файлы там не хранятся.
Например, создали файл, поместили его в СВН - версия1 (revision1). Открыли файл, поставили пробел, сохранили и закоммитили новые изменения  в СВН - версия2  (revision2).
В это время кто-то выгрузил версию1 (revision1) себе на комп, отредактировал ее, добавив пару абзацев. Для него это просто следующая версия, он не в курсе, изменял ли кто-то еще этот файл, но если он сделает правильный коммит в SVN, хранилище распознает все изменения и запишет их под версией3 (revision3).

Правильный означает, что второму пользователю, перед тем как  сделать SVN Commit, нужно сделать SVN Update (выгрузятся изменения документа, хранящиеся в SVN в revision2, о которой он не знал), затем надо сделать SVN Merge (слияние  revision2 и изменений, которые пользователь сделал у себя на компе), и только затем SVN Commit в хранилище.

Неправильный коммит это когда второй пользователь не учел, что в SVN могут кем-то добавиться новые изменения файла (revision2), пока он изменял первую редакцию (revision1) этого файла. Тогда при попытке сделать SVN Commit появится конфликт редакций его рабочей (revision3) и той, что последняя в SVN (revision2).

Цитата
techwriter пишет:
При апдейте изменяется версия.
Изменяется редакция (revision). По названию файла и содержимому не понятно какая редакция хранится в SVN. Понимать можно по SVN Log, в котором видно кто что когда изменил и зачем.

Цитата
ADVANCED пишет:
На самом деле SVN не работает с бинарными файлами
Прошу прощения, ошибаюсь. Последний клиент Tortoise SVN умеет работать с файлами doc и картинками. Но с некоторыми бинарниками и архивами все еще не может. Предыдущие версии не умели делать merge файлы не могли сливаться, а просто дублировались или перезаписывались.  
 
Цитата
techwriter пишет:
Не очень понятно, что имеется в виду под версией редакции файла.
Ну может так разница понятна будет...

Версии документа:
  • Руководство пользователя 1.0.0.1.doc
  • Руководство пользователя 1.0.0.2.doc
  • Руководство пользователя 1.0.0.3.doc
  • Руководство пользователя 1.0.1.1.doc
Версии редакции документа в SVN:

  • Руководство пользователя 1.0.0.1.doc (revision 1453)
  • Руководство пользователя 1.0.0.1.doc (revision 1454)
  • Руководство пользователя 1.0.0.1.doc (revision 1455)
  • Руководство пользователя 1.0.0.1.doc (revision 1501)
Версии программы:
  • Калькулятор v.1.0
  • Калькулятор v.1.2
  • Калькулятор v.3.0
  • Калькулятор v.5.4
Версии редакции исходного файла в SVN, который используется для создания Калькулятор v.3.0:
  • Window1.g.cs (revision 3210)
  • Window1.g.cs (revision 3211)
  • Window1.g.cs (revision 3212)
Изменено: ADVANCED - 28.08.2014 15:28:34
 
Цитата
ADVANCED пишет:
Изменяется редакция (revision). По названию файла и содержимому не понятно какая редакция хранится в SVN. Понимать можно по SVN Log, в котором видно кто что когда изменил и зачем.
Опять же, как организовать процесс. Мы разделили на уровне структуры хранения документа. Путаницы на тему того, с какой версией документа писатель работает, никогда не возникало. Реализовать все можно. Просто вопрос удобства.
techwriter.ru.com
 
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
Изменяется редакция (revision). По названию файла и содержимому не понятно какая редакция хранится в SVN. Понимать можно по SVN Log, в котором видно кто что когда изменил и зачем.
Опять же, как организовать процесс. Мы разделили на уровне структуры хранения документа. Путаницы на тему того, с какой версией документа писатель работает, никогда не возникало. Реализовать все можно. Просто вопрос удобства.
В том то и дело, что это вопрос не структуры, а именно редакций  ;) . Другие варианты "структурирования" предполагают использование копиий файлов. Т.е. в SVN хранятся не изменения, а реальные файлы как на обычном хостинге (100 файлов по 10 Мб = 1Гб). Вернуть содержимое, сохраненное полгода назад, сохранив изменения за последний месяц, и выбросив изменения за 5 месяцев (аналогия с точкой восстановления) будет проблематично. Надо будет открывать каждый файл, сравнивать с предыдущим и копипастить  в третий  :)
Если правильно использовать Merge и разделение проектов на несколько веток, а потом сливать промежуточные воедино, то файл сам по себе будет один, а редакций и рабочих копий множество и всегда можно откатить/накатить ту или иную редакцию.  
 
Цитата
ADVANCED пишет:
Если правильно использовать Merge и разделение проектов на несколько веток, а потом сливать промежуточные воедино, то файл сам по себе будет один, а редакций и рабочих копий множество и всегда можно откатить/накатить ту или иную редакцию.
Не очень поняла, что мешает это все применять в SVN?
techwriter.ru.com
 
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
Если правильно использовать Merge и разделение проектов на несколько веток, а потом сливать промежуточные воедино, то файл сам по себе будет один, а редакций и рабочих копий множество и всегда можно откатить/накатить ту или иную редакцию.
Не очень поняла, что мешает это все применять в SVN?
Это как раз про прямое назначение SVN :)

Цитата
techwriter пишет:
Мы разделили на уровне структуры хранения документа.
Это и мешает применять :) Именно структура, которая не позволяет вернуться к предыдущему варианту (как написано в первом посте).
Если делается несколько копий Версия1, версия2 ... версия 500, то какой смысл их хранить в SVN, если их можно хранить на сетевом диске, доступными для всех?
 
Цитата
ADVANCED пишет:
Это и мешает применять  :)  Именно структура, которая не позволяет вернуться к предыдущему варианту (как написано в первом посте).
Да все можно сделать :))) Вопрос удобства использования и отсутствия конфликтов, и не более того. Отсутствие конфликтов - это человеческий фактор, прежде всего.
Ну, не нравится SVN, можно еще Git рассмотреть.
techwriter.ru.com
 
Цитата
techwriter пишет:
не нравится SVN, можно еще Git рассмотреть
А еще Mercurial и Bazaar. Принцип схожий.
 
Осмелюсь резюмировать вышесказанное.


Цитата
writer пишет:
word не подходит для таких задач, смотрите на ПО, которое позволяет работать над документом нескольким пользователям
Ворд подходит, но при условии хранения в MS SharePoint. SharePoint позволяет работать с документом нескольким пользователям. На 1-2 человека это не актуально,  на организацию >30 чел. вполне, если могут позволить себе подписку. Дороговато в общем.

Цитата
writer пишет:
AuthorIT, Help&Manual (пиратскую версию найти легко)
Это в корне не верный подход   ;)  . Если вы работаете в "шарашкиной конторе" или фрилансер, то вполне подойдет. Но через полгода-год вашим наработкам придет конец. Что-то заглючит, обновится, удалится и т.п. придется покупать лицензию, либо конверитровать в другой формат. А "фирменный" формат  Help&Manual  не так просто конвертнуть во что-то другое без оригинального ПО.

Цитата
writer пишет:
AuthorIT, Help&Manual
Важно проанализировать все "за" и "против" каждого инструмента и принимать решение. Выбрав поначалу простой инструмент, с множеством ненужных возможностей можно столкнуться с большими проблемами при переходк на другой инструмент. А такой переход может быть в силу разных причин: лицензия, расширение форматов, расширение языков, расширение географии офисов и т.п.
Универсальным на сегодняшний день является инструмент на базе XML. Если AuthorIT, Help&Manual и другие позволяют хранить в XML, то лучше так и хранить, а не в специальном "фирменном" формате, который потом только удалить можно.
Также не стоит выбирать сложные инструменты типа Docbook или Dita если их КПД будет стремиться к 0.

Цитата
techwriter пишет:
У нас сейчас планируется переход на Doc-To-Help. Посмотрим, что он нам предложит.
Опять прыгать между word и непонятным форматом ?   :)  
Посмотри еще DITAToo. А тут есть статьи про его возможности. Крутая CMS, но мне не подходит чуток.

А еще все зависит от типа и вида документации, которая нужна. Возможно вполне достаточно будет wiki-системы, которую могут править множество человек. К большинству wiki-движков можно прикрутить экпорт в популярные форматы PDF, DOC, TXT, ePub etc. Настраиваются стили как самой wiki, так и выходных форматов.

Word не моден, не красив, дорог и не всегда удобен. Да и большинству пользователей он не нужен. Разве что в контракте с заказчиком для галочки по ГОСТ...  
Изменено: ADVANCED - 28.08.2014 19:23:03
Страницы: 1 2 След.
Читают тему