Потому, что мы живем в то время, когда подобные стандарты и методологии только девелопятся. Есть море legacy кода и проектов, где все эти ресурсы таки находятся в репозитории с сорцами, и эту ситуацию не исправить в один день запрещением заливать их на гитхаб.
Вы путаете светлое будущее, к которому надо стремиться, с категоричностью запретов.
Ну, разумеется, сабвершн же централизованный. А мы говорим про костыль, делающий таким-же изначально децентрализованную систуму.
Да, я работаю в компании, но все-так же обожаю СПО, как и раньше. Потому у меня есть отдельная машинка в качестве билд-сервера, CI сервера, хранилища бинарников.
Если они хранят свои сорцы на гитхабе, и для тестов им нужны ресурсы в виде этих самых картинок и макетов под вершн контролем, проблема все та-же, что ресурсы делают в системе контроля версий исходного кода, и почему для тестового environment используется локальный клон самого репозитория с исходными кодами тулзы?
Если имелось ввиду, что они пилят диф-тул для SCM, который позволит сравнивать такие типы бинарников, как картинки и макеты, то ради бога. Очень нужная вещь. Только причем тут гитхаб и тем более гит (как системы, не предназначенные версионировать бинарники)?
Попробую сформулировать немного по-другому. Гит — система, очень плохо оптимизированная для версионирования бинарников. Она очень плохо это делает. Может результат многих и устраивает. Но там, внутри, на низком уровне перегона байтиков туда-сюда, ну очень плохо все работает.
Что же для вас «данные для тестов»? Картинки? Не вижу разницы в тестовой картинке и тестовом дапме базы, как ресурса для тестов.
Он их не различает, но способ вычисления дельты, используемый в git, слабо подходит для бинарников. Ибо предполагает генерацию человекочитаемых дельт, коими не являются дельты бинарных файлов.
И причем тут энтерпрайз? По моему тут сейчас вопрос здравого смысла.
А вы представьте себе очень большую мировую контору, где овер 30к программистов, и в каждой команде считают, что 5-10 файлов бинарных в репозитории не помешают.
Вам бы книжку почитать, умную, ибо я не намерен заниматься вашим образованием (бесплатно). Работадатели не мирового уровня пытаются на всем сэкономить, так что не засчитано про ваших предыдущих пятерых. Legacy кода везде хватает, но это не означает, что вот так правильно.
Ладно, с portable версией mysql перегнул. Но вы все равно предлагаете дампы баз с тестовыми данными хранить в репозиториях исходного кода? Хотя, и так вижу, что предлагаете.
Вы спрашиваете, предлагаю ли я картинки и прочее хранить отдельно от кода, когда есть прямые ссылки на них? И сразу же спрашиваете, причем тут менеджеры зависимостей, системы сборки проектов и CI серверы? Ну хватит уже позориться, право, мне за вас уже стыдно. Выучите для начала, что есть все эти умные названия, и потом поймете, возможно, к какой структуре проекта надо стремиться.
И, не забывайте, что гитхаб дает svn доступ, но под этой маской это все тот-же гит. И это преобразование он делает на своей стороне за счет своих вычислительных ресурсов.
Потом из-за таких как вы, у нас корпоративный сервер SVN на кластере в 64 ядра и 512 гигах оперативки еле крутиться (я уж молчу за съеденное место большущего стораджа).
Как я написал выше, largefiles большущий костыль. А тем, кто выступает, что «хорошо бы», пора учить матчасть и не позориться. Если что-то для кого-то хорошо и удобненько, это еще не значит, что это правильненько и не содержит архитектурных ошибочек. И не является лишним растрачиванием ресурсов.
А гитхаб дает svn-доступ, для меня это киллер фича. С дистрибуцией продукта сложнее, да, но гитхаб никогда и не рвался решать подобные проблемы. В конце концов, если это какой-то фрэймворк или либа, то положить ее в популярные серверы зависимостей и все. А если opensource проект более менее развит и известен, как у него может не быть веб-сайта?
Исходники нужно хранить в репозиториях, предназначенных для исходного кода, а бинарники в репозиториях, предназначенных для хранения бинарников. Правильно спроектированные проекты никто не собирает локально (если это не проект, который девелопит один человек на коленке). Для этого есть два таких репозитория (например svn и nexus), система сборки проекта (например, maven), система управления зависимостями, которая для данных сорцов из svn достанет из nexus правильные бинарники (все тот-же maven), и сервер сборки (какой-нибудь jenkins). Локально собирать ничего не надо. Малый участок кода подебажить можно без сборки, а для большого дебага есть тестовый environment и удаленный дебаг.
Нарушающих эту идиллию проектов — море, но это называется legacy и подлежит реорганизации. И тут уж как поступит руководство. Но я бы не работал в конторе, в которой не движутся в правильную сторону.
Вопросы?
Можно, но не нужно. Как сказали выше, это звоночек, что что-то идет не так. У меня например в одном джава проекте с maven сборкой бинарник protobuf.exe лежит прямо в репозитории. Плохо, да, но пока руки не дойдут запаковать его в отдельный артифакт и задеплоить на нексус.
Да, давайте еще portable версию какого-нибудь mysql засовывать в SCM, нужно для тестов же. Еще раз повторюсь, для этого существуют репозитории для бинарников, менеджеры зависимостей, системы сборки проектов и CI серверы. А уж про тестовый environment вы точно должны были слышать.
Вы глубоко заблуждаетесь, как я написал выше, гитхаб предназначет для исходного кода и только, и уж вовсе не является хостингом git репозиториев, ибо предоставляет доступ к одним и тем-же репо для git, hg и svn клиентов. Вы еще по svn хотите бинарники гонять?
По поводу самого git протокола я не так уверен, но все-же склоняюсь к мнению, что для хранения бинарников нужен другой подход и другая архитектура.
Не вижу разницы между тем, нужны ли бинарники для сборки проекта или нет. Я не хочу их загружать в мой девелопмент энвайрмент для фикса, ибо после коммита проект все равно будет собираться на CI сервере, а не локально. Смотрите развернутый ответ здесь. habrahabr.ru/post/184248/#comment_6407226
С largefiles я не знаком, но судя по вашему описанию, это огромный костыль, который ломает всю основную архитектуру mercurial, когда каждый локальный клон является самостоятельным репозиторием. Т.е. я сделал чекаут (клон) какой-то ревизии, и все предыдущие ревизии ко мне попали только в виде какого-то хэша, и я не могу оперировать потом репозиторием локально в оффлайне (если только Бабушкин таки не научился «распаковывать» хэш). И других клонов со своего клона я не могу сделать.
Отлично, храните бинарники в другом месте, привязывайте их декларативно в исходниках с помощью менеджера зависимостей (maven, gradle и прочие для джавы). В чем проблема? Ваш юз кейс очень плохой с моей точки зрения, карать за такое надо, потому что позвольте, но все же мы говорим здесь про гитхаб, а не абстрактно про системы контроля версиями. Ибо и правда, есть системы контроля версиями (тот же Nexus или Artifactory), а есть системы контроля версиями исходного кода. Github это именно второй сервис, и не забываем, что к одному и тому-же репозиторию он предоставляет доступ по svn, git, hg и, возможно, другим протоколам. Особенно ввиду SVN доступа должно становится понятно введение такого лимита.
Вы путаете светлое будущее, к которому надо стремиться, с категоричностью запретов.
Да, я работаю в компании, но все-так же обожаю СПО, как и раньше. Потому у меня есть отдельная машинка в качестве билд-сервера, CI сервера, хранилища бинарников.
Ну ведь вилкой тоже суп кушать можно. Но как-то не удобно.
Если они хранят свои сорцы на гитхабе, и для тестов им нужны ресурсы в виде этих самых картинок и макетов под вершн контролем, проблема все та-же, что ресурсы делают в системе контроля версий исходного кода, и почему для тестового environment используется локальный клон самого репозитория с исходными кодами тулзы?
Если имелось ввиду, что они пилят диф-тул для SCM, который позволит сравнивать такие типы бинарников, как картинки и макеты, то ради бога. Очень нужная вещь. Только причем тут гитхаб и тем более гит (как системы, не предназначенные версионировать бинарники)?
Попробую сформулировать немного по-другому. Гит — система, очень плохо оптимизированная для версионирования бинарников. Она очень плохо это делает. Может результат многих и устраивает. Но там, внутри, на низком уровне перегона байтиков туда-сюда, ну очень плохо все работает.
Он их не различает, но способ вычисления дельты, используемый в git, слабо подходит для бинарников. Ибо предполагает генерацию человекочитаемых дельт, коими не являются дельты бинарных файлов.
И причем тут энтерпрайз? По моему тут сейчас вопрос здравого смысла.
Ладно, с portable версией mysql перегнул. Но вы все равно предлагаете дампы баз с тестовыми данными хранить в репозиториях исходного кода? Хотя, и так вижу, что предлагаете.
Вы спрашиваете, предлагаю ли я картинки и прочее хранить отдельно от кода, когда есть прямые ссылки на них? И сразу же спрашиваете, причем тут менеджеры зависимостей, системы сборки проектов и CI серверы? Ну хватит уже позориться, право, мне за вас уже стыдно. Выучите для начала, что есть все эти умные названия, и потом поймете, возможно, к какой структуре проекта надо стремиться.
Нарушающих эту идиллию проектов — море, но это называется legacy и подлежит реорганизации. И тут уж как поступит руководство. Но я бы не работал в конторе, в которой не движутся в правильную сторону.
Вопросы?
По поводу самого git протокола я не так уверен, но все-же склоняюсь к мнению, что для хранения бинарников нужен другой подход и другая архитектура.
С largefiles я не знаком, но судя по вашему описанию, это огромный костыль, который ломает всю основную архитектуру mercurial, когда каждый локальный клон является самостоятельным репозиторием. Т.е. я сделал чекаут (клон) какой-то ревизии, и все предыдущие ревизии ко мне попали только в виде какого-то хэша, и я не могу оперировать потом репозиторием локально в оффлайне (если только Бабушкин таки не научился «распаковывать» хэш). И других клонов со своего клона я не могу сделать.