Ответы:
Не уверен, насколько хорошо это работает со сжатием данных, но вы можете попробовать git Annex : http://git-annex.branchable.com
Если ваши файлы не такие большие, лучше всего подойдет обычный git или mercurial. Просто избегайте SVN любой ценой
Есть несколько хороших предложений по адресу /programming/29292/version-control-for-graphics
Вот несколько цитат из вопроса на http://StackOverflow.com
"Github недавно представил" режимы просмотра изображений ", посмотрите: https://github.com/blog/817-behold-image-view-modes "
-
«Я успешно использовал перформанс в очень больших проектах (+100 ГБ), однако нам пришлось обернуть доступ к серверу управления версиями чем-то более дружественным для художника».
-
«TortoiseSVN может показывать ревизии изображений бок о бок, что действительно полезно. Я использовал его с разными командами с большим успехом. Художникам нравилось иметь возможность откатывать вещи (после того, как они привыкли к концепциям). ). Хотя это занимает много места. "
Timeline работает с любым svn и, по-видимому, также является плагином для дизайна.
SVN, вероятно, здесь в основном не по теме, но в двух словах: он отслеживает один исходный файл, а затем сохраняет изменения в этом исходном файле с течением времени, или вы заставляете новую «базовую точку».
Единственный способ надежно вернуться к более старой версии - это сравнить их вручную и принять решение. Изначально репозитории предназначались главным образом для простых текстовых файлов (с исходным кодом), и довольно просто посмотреть на необработанные изменения и решить, какие вы хотите, потому что они были удобочитаемыми для начала, но для двоичных данных (изображений, собственных форматов, форматов контейнеров). и т.д.), изменения не в удобочитаемой форме. Временная шкала выглядит как способ справиться с этим, принимая различные коммиты и отображая их.
Ссылка Скотта на изображение GIT предназначена для определенных форматов и ( я предполагаю ), вероятно, не поддерживает файлы PSD и особенно файлы indesign (то есть случайные двоичные форматы). Временная шкала, похоже, представляет собой плагин, который просто использует хост-приложение для представления двоичных данных (хорошее решение, по крайней мере, на бумаге IMO).
Основной способ работы репозитория SVN заключается в том, что у вас есть серверный процесс, который обрабатывает отслеживание и первичное хранение всех различий. Затем у вас есть клиентский процесс на вашем рабочем компьютере, который всегда запускается и подключается к контекстным меню и т. Д. (Или использует командную строку). Вы создаете локальную пустую папку и затем помечаете ее как папку SVN, «проверяя» версию из репозитория на сервере. С этого момента вы можете редактировать их, как вам нравится, но вы должны использовать клиент SVN для перемещения копирования или удаленияфайл (ы) в файловой системе. Если вы добавляете какие-либо новые файлы в локальную папку SVN, вы должны пометить их для отслеживания. Все это происходит локально, и репо обновляется только с любыми ревизиями, когда вы вручную «фиксируете» обратно в репо. Ваша локальная копия является единственной версией, и вам нужно связаться с сервером SVN, чтобы восстановить файл.
Все это медленно по сравнению с отсутствием SVN, даже для текстовых файлов, особенно если вы просматриваете большой проект. Проекты, в которых я использовал SVN (прошедшее время), были в основном основаны на исходном коде, с 20-30 тысячами маленьких файлов, а полная проверка требовала перерыва на кофе. Я подозреваю, что это было больше из-за пропускной способности из-за большого количества маленьких файлов, и меньшее количество больших двоичных файлов того же размера хранения было бы быстрее.
GIT работает немного по-другому, я думаю.
Я использую git для своих проектов в Illustrator и InDesign. Я должен признать, что управлять проектами не так просто. Вот несколько советов, которые я хотел бы помочь вам:
Просто будьте осторожны с SVN, я бы выучил git. Это лучше с огромными размерами файлов, но все же выполняет контроль / управление Subversion. Просто более легкий.
Большинство систем управления версиями предназначены для работы с недвоичными форматами файлов. Другими словами, текстовые файлы.
Они легкие, легко разбиваются, разветвляются, объединяются и отслеживают постепенные изменения.
Системы типа SVN и GIT не предназначены для обработки PSD-файлов. Это гигантские файлы, которые нелегко сопоставить из одной версии в другую, и их невозможно «объединить», разветвить и тому подобное.
Некоторые могут разрешать двоичные файлы - я полагаю, что SVN делает, но по моему опыту, он не пытается их версии. Вместо этого он просто заменяет последнюю версию. Так что там ограниченного использования.
Кроме того, если вы научитесь работать с моделью контроля версий, вы научитесь часто регистрироваться. Это отлично подходит для кода, но скоро увеличит ваш репозиторий до неуправляемых размеров, если вы проверяете версии PSD-файлов размером 100 МБ каждые 20 минут.
Из-за отсутствия ветвления и тому подобного это означает, что вы, скорее всего, будете делать это вручную, имея несколько копий слегка подправленных файлов. Это, увы, означает еще большие файлы, которые нужно хранить, чтобы еще один удар по использованию контроля версий.
Таким образом, для тяжелых двоичных файлов вы захотите оставить внешнюю систему управления версиями, подобную этой, и изучить инструменты DAM (Digital Asset Management).
Увы, не так много систем контроля версий, разработанных специально для тяжелых документов. Sharepoint один, но он неуклюжий, трудно автоматизируемый и редко настраивается для обработки файлов размером с PSD.
Наиболее вероятной альтернативой является собственная версия Adobe Cue, которая, как мне кажется, была превращена в продукт «Adobe Drive»: