Как использовать Subversions для Indesign, Illustrator и Photoshop

9

Я нашел инструмент Timeline от Pixel Novel, но мне было интересно, смогу ли я использовать какое-либо приложение subversions для управления своими файлами дизайна. Я не уверен, что понимаю все о Subversions, и я не нашел много информации о его использовании в области дизайна.

Джолин М
источник

Ответы:

4

Не уверен, насколько хорошо это работает со сжатием данных, но вы можете попробовать git Annex : http://git-annex.branchable.com

Если ваши файлы не такие большие, лучше всего подойдет обычный git или mercurial. Просто избегайте SVN любой ценой

paul.ago
источник
Звучит интересно!
Джолин М,
3

Есть несколько хороших предложений по адресу /programming/29292/version-control-for-graphics

Вот несколько цитат из вопроса на http://StackOverflow.com

"Github недавно представил" режимы просмотра изображений ", посмотрите: https://github.com/blog/817-behold-image-view-modes "

-

«Я успешно использовал перформанс в очень больших проектах (+100 ГБ), однако нам пришлось обернуть доступ к серверу управления версиями чем-то более дружественным для художника».

-

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

гулянка
источник
Спасибо за ссылки; Я действительно надеялся получить опыт работы с InDesign.
Джолин М
Что касается изображений и файлов дизайна, различия минимальны. Я подозреваю, что функция «изображения рядом» имеет дело с подмножеством форматов изображений, однако для файлов indesign представленные различия будут двоичными и, следовательно, будут бесполезными без проверки копии более ранней ревизии.
Горацио
2

Timeline работает с любым svn и, по-видимому, также является плагином для дизайна.

SVN, вероятно, здесь в основном не по теме, но в двух словах: он отслеживает один исходный файл, а затем сохраняет изменения в этом исходном файле с течением времени, или вы заставляете новую «базовую точку».

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

Ссылка Скотта на изображение GIT предназначена для определенных форматов и ( я предполагаю ), вероятно, не поддерживает файлы PSD и особенно файлы indesign (то есть случайные двоичные форматы). Временная шкала, похоже, представляет собой плагин, который просто использует хост-приложение для представления двоичных данных (хорошее решение, по крайней мере, на бумаге IMO).

Основной способ работы репозитория SVN заключается в том, что у вас есть серверный процесс, который обрабатывает отслеживание и первичное хранение всех различий. Затем у вас есть клиентский процесс на вашем рабочем компьютере, который всегда запускается и подключается к контекстным меню и т. Д. (Или использует командную строку). Вы создаете локальную пустую папку и затем помечаете ее как папку SVN, «проверяя» версию из репозитория на сервере. С этого момента вы можете редактировать их, как вам нравится, но вы должны использовать клиент SVN для перемещения копирования или удаленияфайл (ы) в файловой системе. Если вы добавляете какие-либо новые файлы в локальную папку SVN, вы должны пометить их для отслеживания. Все это происходит локально, и репо обновляется только с любыми ревизиями, когда вы вручную «фиксируете» обратно в репо. Ваша локальная копия является единственной версией, и вам нужно связаться с сервером SVN, чтобы восстановить файл.

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

GIT работает немного по-другому, я думаю.

Горацио
источник
Это проясняет некоторые вещи. Я полагаю, что не хватает плавности управления файлами в поисковике; может быть трудно реализовать в команде дизайнеров, которые не привыкли к этой системе. Я думаю, что я попробую программное обеспечение Timeline и посмотрю, как оно идет.
Джолин М
2

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

  • используйте прямую ветвь для создания резервных копий вашего дизайна;
  • попытайтесь извлечь ваши переменные и текстовые данные в XML: это работает для меня в дизайне Illustrator с переводом текста на несколько языков;
  • не создавайте вилки для разных версий дизайна (раньше я так думал и закончил несколькими несмываемыми и несравненными публикациями);
  • использовать внешнее приложение, такое как WinMerge, для копирования-вставки и сравнения текстов из InDesign / Illustrator, это немного противоречит идеологии SVN, но ближе к исправлению опечаток и быстрому сравнению версий содержимого публикации без необходимости экспорта текста;
  • Пересмотрите способ хранения своих дизайнов: внешние ссылки и библиотеки (цветов, символов и т. д.) лучше, чем один большой файл.
amrok
источник
Под XML вы подразумеваете текст с тегами Adobe Indesign ?
Лулалала
0

Просто будьте осторожны с SVN, я бы выучил git. Это лучше с огромными размерами файлов, но все же выполняет контроль / управление Subversion. Просто более легкий.

dmanexe
источник
Не могу подтвердить это своими собственными экспериментами с репозиторием с некоторыми ревизиями в обеих системах. Но это может зависеть от рассматриваемых файлов.
Мнемент
0

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

Они легкие, легко разбиваются, разветвляются, объединяются и отслеживают постепенные изменения.

Системы типа SVN и GIT не предназначены для обработки PSD-файлов. Это гигантские файлы, которые нелегко сопоставить из одной версии в другую, и их невозможно «объединить», разветвить и тому подобное.

Некоторые могут разрешать двоичные файлы - я полагаю, что SVN делает, но по моему опыту, он не пытается их версии. Вместо этого он просто заменяет последнюю версию. Так что там ограниченного использования.

Кроме того, если вы научитесь работать с моделью контроля версий, вы научитесь часто регистрироваться. Это отлично подходит для кода, но скоро увеличит ваш репозиторий до неуправляемых размеров, если вы проверяете версии PSD-файлов размером 100 МБ каждые 20 минут.

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

Таким образом, для тяжелых двоичных файлов вы захотите оставить внешнюю систему управления версиями, подобную этой, и изучить инструменты DAM (Digital Asset Management).

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

Наиболее вероятной альтернативой является собственная версия Adobe Cue, которая, как мне кажется, была превращена в продукт «Adobe Drive»:

http://www.adobe.com/products/adobedrive.html

DA01
источник
Subversion, Git, Bazaar и другие современные VCS поддерживают двоичные файлы, вы можете вернуться к любой более ранней версии и создать ветки. Однако слияние правок (в разных ветвях) приведет к конфликту, и вам придется выбрать одну версию.
Млемент
@Mnementh Я бы сказал, что есть разница между «поддержкой» и «разработкой, чтобы справиться». С SVN или GIT дело в том, что если вы попытаетесь выяснить разницу между 8 версиями PSD-файла размером 40 Мб, это станет проблемой. Я бы сказал, что вы не сильно выигрываете от использования SVN / GIT в этом контексте. Инкрементные резервные копии, вероятно, будут более практичными.
DA01