Comments 38
Тема интересная, но под фото, видео и документы можно обойтись и Seafile`ом.
Простите, а где картинка с трамваем из буханки?
Ах, вот, что вы имеете ввиду!
Нет, не соглашусь. Здесь всё ванильно!
Git в значительной степени лично Торвальдс сделал, а Sitaram Chamarty, основной разработчик gitolite, как минимум с Торвальдсом переписывался.
Нет, не соглашусь. Здесь всё ванильно!
Git в значительной степени лично Торвальдс сделал, а Sitaram Chamarty, основной разработчик gitolite, как минимум с Торвальдсом переписывался.
Троллейбусом :3
Ну хватит уже использовать неподходящие инструменты, ну пожалуйста!
После фразы " Как оказалось, GIT с большим трудом справляется с этой задачей" должна была быть фраза «Наверное он для этого не подходит, возьму-ка я Фликр или Пикасу». И на этом закончить
После фразы " Как оказалось, GIT с большим трудом справляется с этой задачей" должна была быть фраза «Наверное он для этого не подходит, возьму-ка я Фликр или Пикасу». И на этом закончить
Вы про фликр или пикасу не подумав сказали? Откуда там версионность?
Задачка то вполне себе близка к реальности — вот у меня ресурсы для игры, в том числе результирующие атласы в виде графических файлах в различных формата + файлы описание. Гигабата на полтора только результат + еще гигабайт на 5 промежуточных данных + еще гигабайтик исходников. Время конвертации всегода добра 40+ часов.
При этом мне необходимо иметь возможность откатиться на нужный тег (чтобы иметь возможность вернуться к данным определенного релиза), нужно иметь возможность понимать какие файлы после очередной пересборке поменялис, нужно иметь возможность различным людям как и добавлять исходные файлы, так и забирать результат. При этом я таки хочу иметь возможность комитить в оффлайне.
Что мне предлагаете кроме git/hg использовать?
Так, что по мне так спасибо автору большое — глядишь у меня git status начнет работать не по 20 минут после очередной пересборки ресурсов (хотя у меня проблема скорее в количестве файлов).
Задачка то вполне себе близка к реальности — вот у меня ресурсы для игры, в том числе результирующие атласы в виде графических файлах в различных формата + файлы описание. Гигабата на полтора только результат + еще гигабайт на 5 промежуточных данных + еще гигабайтик исходников. Время конвертации всегода добра 40+ часов.
При этом мне необходимо иметь возможность откатиться на нужный тег (чтобы иметь возможность вернуться к данным определенного релиза), нужно иметь возможность понимать какие файлы после очередной пересборке поменялис, нужно иметь возможность различным людям как и добавлять исходные файлы, так и забирать результат. При этом я таки хочу иметь возможность комитить в оффлайне.
Что мне предлагаете кроме git/hg использовать?
Так, что по мне так спасибо автору большое — глядишь у меня git status начнет работать не по 20 минут после очередной пересборки ресурсов (хотя у меня проблема скорее в количестве файлов).
я предлагаю не использовать source control для бинарников. Потому что у слова «source» есть смысл, отличный от смысла слова «binary». Для бинарников предлагаю использовать хранилище бинарников. Вот такая оригинальная идея.
П.С. На счет фликера и пикасы — виноват, погорячился, вспылил.
П.С. На счет фликера и пикасы — виноват, погорячился, вспылил.
Критикуешь предлагай? А что использовать то? FTP с папочками?
Привязываться к терминам — у меня вот по своей сути большая часть инфы это исходники для ресурсов, а уж их формат не важен. Вы же не только исходники храните в вашем проекте — там небось и файл проекта есть бинарный зачастую, и пару тройку картинок — что неужели в каком то web проекте, предлагаете не хранить картинки в репозитарии, а держать отдельно?
Понятно что есть assets manager-ы типа AlienBrain — но цена у них…
Так, что как бы вам не нравилось — но по миру тысячи компаний используют системы контроля версий для бинарных файлов.
Привязываться к терминам — у меня вот по своей сути большая часть инфы это исходники для ресурсов, а уж их формат не важен. Вы же не только исходники храните в вашем проекте — там небось и файл проекта есть бинарный зачастую, и пару тройку картинок — что неужели в каком то web проекте, предлагаете не хранить картинки в репозитарии, а держать отдельно?
Понятно что есть assets manager-ы типа AlienBrain — но цена у них…
Так, что как бы вам не нравилось — но по миру тысячи компаний используют системы контроля версий для бинарных файлов.
Предлагаю — binary repository manager.
Он умеет работать с бинарниками (правильно их версировать, дешево хранить, не пытаться делать diff, не пытаться клонировать весь репозиторий на каждую машину, и т.д.)
Есть несколько бесплатных альтернатив.
Ну, когда-то тысячи компаний по миру строили свои проекты на машинах девелоперов. Ничего, научились CI, научатся различать между сорцами и бинарниками (большинство, кстати, уже умеют).
Он умеет работать с бинарниками (правильно их версировать, дешево хранить, не пытаться делать diff, не пытаться клонировать весь репозиторий на каждую машину, и т.д.)
Есть несколько бесплатных альтернатив.
по миру тысячи компаний используют системы контроля версий для бинарных файлов.
Ну, когда-то тысячи компаний по миру строили свои проекты на машинах девелоперов. Ничего, научились CI, научатся различать между сорцами и бинарниками (большинство, кстати, уже умеют).
А можно все же конкретный пример? А то в гугле по запросу «binary repository manager» вылезает JFrog какой-то — который явно не то что мне нужно.
Задачи я описал выше, могу рассказать подробнее. Можно конкретную утилиту для этого?
Задачи я описал выше, могу рассказать подробнее. Можно конкретную утилиту для этого?
Binary repository — это то как раз то что вы пытаетесь сделать, и то что вы нашли — это как раз то что нужно.
Конечно третий час ночи не лучший момент, но я все же не понимаю — каким образом оное может мне помочь.
Вы сейчас говорите про Artifactory? Я посмотрел скринкаст — и совершенно не понимаю как оно мне может помочь.
Вы можете уделить 5 минут и последовательно рассказать чем мне оно может помочь?
Задача простая — есть 200к файлов размером 5гигов. Нужно иметь версионность, нужно иметь возможность просмотреть какие файлы изменились, нужно иметь возможность избранно комитить.
Какой сценарий с Artifactory?
Вы сейчас говорите про Artifactory? Я посмотрел скринкаст — и совершенно не понимаю как оно мне может помочь.
Вы можете уделить 5 минут и последовательно рассказать чем мне оно может помочь?
Задача простая — есть 200к файлов размером 5гигов. Нужно иметь версионность, нужно иметь возможность просмотреть какие файлы изменились, нужно иметь возможность избранно комитить.
Какой сценарий с Artifactory?
Мне показалось, что его «архитектура» вполне пригодна для больших репозиториев. За год-другой он дозреет. Ему бы «более поточный» алгоритм поиска «дельт», и отказаться от проецирования файлов в память в пользу файлов с произвольным доступом.
Архитектура Git-а не пригодна для бинарников. Сколько костылей не строй, каменный цветок не выйдет.
А вот hg c bigfiles более менее пригодна, так что не нужно на dvcs гнать вообще — это сугубо git заморочки.
git еще много для чего не пригоден — типа для кучи файлов просто большой и т.п.
Но опять же альтернативы?
git еще много для чего не пригоден — типа для кучи файлов просто большой и т.п.
Но опять же альтернативы?
Любая dvcs не пригодна для больших репозиториев, просто потому что она «d», и пихает на все машины весь репозиторий. Если в svn я еще мог сказать «давай мне src, а вот lib не давай», то в dvcs — никак. Получай, батенька, парочку террабайт, даже если они тебе не нужны.
Альтернативы см. выше.
Альтернативы см. выше.
Думаю, это как раз тот случай, когда лучше не использовать cvs взять svn и запастись большими дисками и терпением :)
Почему все обсуждают непригодность репозиториев для версионирования бинарников? По-моему версионирование изображений как бинарников — изначально неверный путь. Наиболее логичный подход у Lightroom. Хранить исходник и правки в виде метаданных. Репозиторий не раздувается при каждом сохранении, накладные расходы почти нулевые.
Единственное, что не встречал пока распределенного решения с такой архитектурой.
Единственное, что не встречал пока распределенного решения с такой архитектурой.
UFO just landed and posted this here
Git это тоже система контроля версий. Для сорцов. Как и Perforce и SVN (про него выше только что написал). Разница не в том, что есть для версий, а есть нет, а в том, что есть для сорцов а есть для бинарников.
Идея хорошая, только если это личные фотографии то нужно иметь закрытый аккаунт.
Иначе может повториться история как из clip2net:
P.S. (топик на Хабре уже закрылся).
Иначе может повториться история как из clip2net:
P.S. (топик на Хабре уже закрылся).
Бинарный файл лучше хранить в оригинале и в RAW виде (если он действительно ценнен), а вот конфиги фильтров и правок как например в Lightroom (за исключением brush редактирования) очень даже имеет смысл хранить в версиях (возможно) — кроп, экспозиция, уровни, тонирование и тп. Версионные данные бинарных файлов изображений — избыточные, и вероятность их использования очень мала. Это мой взгляд из практики работы с большими массивами raw фото.
да, непонятно, зачем использовать git, если для таких применений предназначен rsync
Но зачем?
Когда есть dropbox, skydrive, google drive и тп.
Когда есть dropbox, skydrive, google drive и тп.
Вы случайно не git-annex пытаетесь изобрести?
git-annex.branchable.com/
статья на русском — welinux.ru/post/7157/
git-annex.branchable.com/
статья на русском — welinux.ru/post/7157/
Спасибо за наводку. Очень интересно.
Не уверен, что хочу что-то изобрести. На мой взгляд Git должен (и, уверен, будет) справляться с репозиториями больших размеров.
* Если много мелких файлов — гит упакует их в пак.
* Большая глубина вложенности — не проблема (листинг одного каталога в отдельном файле со ссылками на листинги вложенных).
* Огромное количество правок одного файла — гит запишет последний вариант целиком, а предыдущие может сократить и заменить «дельтами».
Потенциально проблемное место — файлы более 2G. Их git не будет разбивать на несколько. Т.е. положить такой репозиторий на файловую систему не поддерживающую большие файлы не удастся. Или клонировать через древний http сервер, тоже могут быть проблемы. Однако более-менее современные системы без труда обслуживают такие файлы.
И еще одно место с потенциалом неоптимального функционирования — это дельты. Git хранит последнюю версию файла, а предыдущие, если есть резон упаковывает в дельты (при упаковке).
Т.е.
Добавим файл в 1000 строк и закомитим. (в репозитории лежит файл в 1000 строк)
Изменим 1 строчку и закомитим. (в репозитории лежат 2 файла по 1000 строк!)
Выполним git gc. (В репозитории 1 пак 1001 стока и 1 индек 2 строки — примерно)
Изменим еще одну строчку и закомитим. (в репозитории 1 индек 2 строки, 1 пак 1001 строка, 1 файл 1000 строк).
Опять git gc. И вот тут Git-у во-первых приходится переделывать все паки в которых есть версии файлов изменившихся с последней упаковки. А во-вторых ранее существовавшие паки оказывается устаревшим.
Не уверен, что хочу что-то изобрести. На мой взгляд Git должен (и, уверен, будет) справляться с репозиториями больших размеров.
* Если много мелких файлов — гит упакует их в пак.
* Большая глубина вложенности — не проблема (листинг одного каталога в отдельном файле со ссылками на листинги вложенных).
* Огромное количество правок одного файла — гит запишет последний вариант целиком, а предыдущие может сократить и заменить «дельтами».
Потенциально проблемное место — файлы более 2G. Их git не будет разбивать на несколько. Т.е. положить такой репозиторий на файловую систему не поддерживающую большие файлы не удастся. Или клонировать через древний http сервер, тоже могут быть проблемы. Однако более-менее современные системы без труда обслуживают такие файлы.
И еще одно место с потенциалом неоптимального функционирования — это дельты. Git хранит последнюю версию файла, а предыдущие, если есть резон упаковывает в дельты (при упаковке).
Т.е.
Добавим файл в 1000 строк и закомитим. (в репозитории лежит файл в 1000 строк)
Изменим 1 строчку и закомитим. (в репозитории лежат 2 файла по 1000 строк!)
Выполним git gc. (В репозитории 1 пак 1001 стока и 1 индек 2 строки — примерно)
Изменим еще одну строчку и закомитим. (в репозитории 1 индек 2 строки, 1 пак 1001 строка, 1 файл 1000 строк).
Опять git gc. И вот тут Git-у во-первых приходится переделывать все паки в которых есть версии файлов изменившихся с последней упаковки. А во-вторых ранее существовавшие паки оказывается устаревшим.
Я просто оставлю это здесь: layervault.com/tour
Это аналог Dropbox с неограниченным объемом хранения за фиксированную ежемесячную плату ($24), который имеет систему контроля версий специально для графических файлов
Это аналог Dropbox с неограниченным объемом хранения за фиксированную ежемесячную плату ($24), который имеет систему контроля версий специально для графических файлов
О! случайно наткнулся! Хорошая идея чтобы с домашнего компа делать бекапы фоток на внешний жесткий диск. Никогда не знаешь что в этом ворохе папок добавилось, а что, может переименовалось (например после опечатки), а тут настроить репозиторий и заливать на винч только то что изменилось. Спасибо. Обязательно попробую эти настройки Git'а.
Вместо настроек, которые я привел в статье я бы очень рекомендовал Git Large File Storage (LFS) https://git-lfs.github.com/
Sign up to leave a comment.
Git для Фоток. Большие репозитарии в Git