Мы в этой ветке тоже немного затронули эту тему, но там как-то нормальной дискуссии не получилось.
У меня есть и за и против хранения бинарников в репозитории. Мне кажется тут уж очень сильно все зависит от того, что вы разрабатываете и как.
1. Если вы сами пишите эти тулзы или библиотеки, а так же у вас есть возможность собрать любую версию в любое время — не стоит их запихивать в репозитории проектов. Пишите скрипты. То есть согласен с вами в этом случае.
2. Если вы пишите сервис, вам не нужно поддерживать 2х годовалые версии вашего продукта, вы легко переходите на новые версии библиотек. Опять же, не стоит складывать чужие бинарники к себе в репозиторий. Просто нет смысла.
3. Если вы пишите свой собственный продукт, вам необходимо поддерживать 2х годовалые проекты — в этом случае просто необходимо хранить где-то эти самые чужие зависимости. Так как вы просто не знаете, будет ли тот сайт, где вы скачали библиотеку существовать через 2 года или нет. Хранить их просто где-то — нужно делать бекапы, писать какие-то скрипты, которые бы как-то делали mapping вашей текущей версии из определенного branch на определенные версии этих библиотек. А можно сделать проще — положить все библиотеки в сам branch и больше никаких проблем — есть 1-1 mapping, есть история, знаете когда и что обновляли, а так же в любой момент времени можете собрать текущую версию. Если кто-то сломал этот самый build script, то он сломан в одном branch, а не для всей компании. Прикиньте, например, как бы вы это поддерживали, если бы у вас было, например, 200 разработчиков в компании с 20 branches.
Ну думаю, что я готов вам дать такой обзор.
У обоих систем есть свои плюсы и недостатки, не хотел бы выступать в плане Git vs Perforce. Я вижу, что нам с Git как организации было бы сложнее. С другой стороны, я не представляю, как бы я мучился, если бы не было git p4.
Не знаю, была ли проблема с атрибутами. Как я уже говорил, я особо этим не занимаюсь, пришел на готовое. Сам думаю, что не было никаких особых проблем с атрибутами, хотя все может быть. На самом деле, думаю, что так просто проще обновляться:
* История самих этих библиотек нам не нужна.
* Иногда нужно хранить несколько версий самой библиотеки.
* С tar.gz просто сравнить, что у нас точно тоже самое, что сейчас лежит на сайте у производителя библиотеки, по хешу.
В общем, мне кажется, это чисто для удобства обновления и слежения за версиями. Распаковка занимает конечно какое-то время, но это лечится при помощи increment build.
> А у вас чем-то из перечисленного занимается perforce?
Может я не верно высказался, но как бы да. Perforce понятное дело бекапится постоянно. Плюс он дает гарантию, что у нас явное соответствие того, что для определенного бранча в этом бранче лежат определенные версии библиотек, за этим следить не нужно. Случайно никто ничего не удалит и не порушит, так как в perforce есть история, ну и как я уже сказал — есть бекапы. Все, вроде, логично.
> Ну тогда понятно, зачем ежедневные деплои :)
Вы сделали не верные выводы. Если интерес в разговоре был только в том, чтобы доказать, что вы умный, а я глупый, то давайте на этом закончим.
> А я могу кратко, что в сравнении с вашим «попробую» как бы намекает :)
Не понимаю намека.
> Так вот на этой же файловой системе с правами доступа -r------- (400) и есть самое распрекрасное место для архива.
Положить что-то куда-то — это только часть беды. За этим нужно следить — backups, version control (в смысле, что нужно знать, какая версия какой библиотеки используется в каком бранче, для какой версии и т.п.). Так после этого назревает только один вопрос. В чем прелесть по сравнению с хранением их в perforce? Только то, что репозитории будут меньше? Такой проблемы нет, perforce справляется более чем хорошо с этим.
> Что касается ноды, то деплой обычно ждет даже неделю. Ну если это не первый мой проект, который я мечтаю показать всему миру немедленно.
git-annex инетесное решение. Но, как уже сказали — мы используем perforce.
В случае git + git-annex — нужно поддерживать две системы, а в случае perforce — только одну. Думаю для людей, сопровождающих наш репозиторий и билд окружение — выбор будет очевидным. Я бы выбрал perforce.
Хранить или не хранить — это холиварный вопрос. Если вам действительно хочется об этом поговорить именно со мной, то мы, конечно, можем. Но скажу так, я не занимаюсь build системой в компании, в которой я сейчас работаю. Существует она уже порядка 10 лет. Работает она отлично, намного лучше, чем в Visual Studio (где я раньше работал). Проблем у меня с ней совсем нет, поэтому мне нравится и я не жалуюсь.
Отвечая на ваш вопрос, попробую кратко. На вскидку у нас есть 30 проектов от которых мы зависим как-то (используем в билде, используем при поставке своего продукта, используем сам компонент и т.п.), из этого следует:
а) Не хранить их где-то глупо, так как кто знает, может быть завтра github будет лежать, а послезавтра bitbucket. Над этим, я думаю, мы согласимся.
б) Копировать и хранить их в какой-нибудь специальной системе, откуда забирать — вроде как, разумно. Но тогда нужно будет поддерживать и perforce/git, а так же эту вторую систему. Какой смысл в этом будет смысл, если perforce отлично может управляться с большими файлами?
Могу еще немного подитожить. Если все зависимости можно получить из одного места, как например npm (node.js) или nuget (microsoft), и если вы довольны uptime этих систем, то можно не хранить в репозиториях, а подтягивать их при билде, например. Но опять же из примеров, после того, как npm пару дней работал в нестабильном режиме и народ не мог сделать deploy своих node.js проектов — мне интересно, сколько народу после этого убрало node_modules из .gitignore.
tar.gz, если любопытно. В них содержатся всякое, чаще всего исходники каких-нибудь сторонних продуктов, библиотек, утилит, которые используются при сборке, при поставке и т.п.
Мне, в принципе, perforce нравится. Шустрый, огромное количество команд. Иногда, конечно, приходится покопаться долго, чтобы разобраться, как нужно заставить его сделать то, что необходимо. Но после того, как поработаешь с ним месяц — запомнишь все стандартные подходы — все становится намного проще. Я, практически, все делаю из командной строки, если это важно.
Правда для development использую «git p4», так как приходится часто переключаться между задачами. В моем случае репозиторий одного бранча без истории получается около 2.3Gb (только папка .git), если кому интересно.
Если есть вопросы — с радостью отвечу.
У меня есть и за и против хранения бинарников в репозитории. Мне кажется тут уж очень сильно все зависит от того, что вы разрабатываете и как.
1. Если вы сами пишите эти тулзы или библиотеки, а так же у вас есть возможность собрать любую версию в любое время — не стоит их запихивать в репозитории проектов. Пишите скрипты. То есть согласен с вами в этом случае.
2. Если вы пишите сервис, вам не нужно поддерживать 2х годовалые версии вашего продукта, вы легко переходите на новые версии библиотек. Опять же, не стоит складывать чужие бинарники к себе в репозиторий. Просто нет смысла.
3. Если вы пишите свой собственный продукт, вам необходимо поддерживать 2х годовалые проекты — в этом случае просто необходимо хранить где-то эти самые чужие зависимости. Так как вы просто не знаете, будет ли тот сайт, где вы скачали библиотеку существовать через 2 года или нет. Хранить их просто где-то — нужно делать бекапы, писать какие-то скрипты, которые бы как-то делали mapping вашей текущей версии из определенного branch на определенные версии этих библиотек. А можно сделать проще — положить все библиотеки в сам branch и больше никаких проблем — есть 1-1 mapping, есть история, знаете когда и что обновляли, а так же в любой момент времени можете собрать текущую версию. Если кто-то сломал этот самый build script, то он сломан в одном branch, а не для всей компании. Прикиньте, например, как бы вы это поддерживали, если бы у вас было, например, 200 разработчиков в компании с 20 branches.
У обоих систем есть свои плюсы и недостатки, не хотел бы выступать в плане Git vs Perforce. Я вижу, что нам с Git как организации было бы сложнее. С другой стороны, я не представляю, как бы я мучился, если бы не было git p4.
* История самих этих библиотек нам не нужна.
* Иногда нужно хранить несколько версий самой библиотеки.
* С tar.gz просто сравнить, что у нас точно тоже самое, что сейчас лежит на сайте у производителя библиотеки, по хешу.
В общем, мне кажется, это чисто для удобства обновления и слежения за версиями. Распаковка занимает конечно какое-то время, но это лечится при помощи increment build.
Может я не верно высказался, но как бы да. Perforce понятное дело бекапится постоянно. Плюс он дает гарантию, что у нас явное соответствие того, что для определенного бранча в этом бранче лежат определенные версии библиотек, за этим следить не нужно. Случайно никто ничего не удалит и не порушит, так как в perforce есть история, ну и как я уже сказал — есть бекапы. Все, вроде, логично.
> Ну тогда понятно, зачем ежедневные деплои :)
Вы сделали не верные выводы. Если интерес в разговоре был только в том, чтобы доказать, что вы умный, а я глупый, то давайте на этом закончим.
Не понимаю намека.
> Так вот на этой же файловой системе с правами доступа -r------- (400) и есть самое распрекрасное место для архива.
Положить что-то куда-то — это только часть беды. За этим нужно следить — backups, version control (в смысле, что нужно знать, какая версия какой библиотеки используется в каком бранче, для какой версии и т.п.). Так после этого назревает только один вопрос. В чем прелесть по сравнению с хранением их в perforce? Только то, что репозитории будут меньше? Такой проблемы нет, perforce справляется более чем хорошо с этим.
> Что касается ноды, то деплой обычно ждет даже неделю. Ну если это не первый мой проект, который я мечтаю показать всему миру немедленно.
Мы живем с вами в разных мирах.
В случае git + git-annex — нужно поддерживать две системы, а в случае perforce — только одну. Думаю для людей, сопровождающих наш репозиторий и билд окружение — выбор будет очевидным. Я бы выбрал perforce.
Отвечая на ваш вопрос, попробую кратко. На вскидку у нас есть 30 проектов от которых мы зависим как-то (используем в билде, используем при поставке своего продукта, используем сам компонент и т.п.), из этого следует:
а) Не хранить их где-то глупо, так как кто знает, может быть завтра github будет лежать, а послезавтра bitbucket. Над этим, я думаю, мы согласимся.
б) Копировать и хранить их в какой-нибудь специальной системе, откуда забирать — вроде как, разумно. Но тогда нужно будет поддерживать и perforce/git, а так же эту вторую систему. Какой смысл в этом будет смысл, если perforce отлично может управляться с большими файлами?
Могу еще немного подитожить. Если все зависимости можно получить из одного места, как например npm (node.js) или nuget (microsoft), и если вы довольны uptime этих систем, то можно не хранить в репозиториях, а подтягивать их при билде, например. Но опять же из примеров, после того, как npm пару дней работал в нестабильном режиме и народ не мог сделать deploy своих node.js проектов — мне интересно, сколько народу после этого убрало node_modules из .gitignore.
Правда для development использую «git p4», так как приходится часто переключаться между задачами. В моем случае репозиторий одного бранча без истории получается около 2.3Gb (только папка .git), если кому интересно.
Но все равно поздравляем!