1. Вы не назвали ни единого преимущества своего решения кроме «мы так привыкли» и «нам так проще».
Назвал.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
И там вопрос, кстати, было бы интересно услышать как это делается у вас.
2. Из недостатков моего решения вы назвали только «зачем городить огород».
Это не правда.
В кратце:
1) Скорость не страдает, термин «чистота» не раскрыт.
Где здесь «нам так удобнее»?
2) Сложность коммита не раскрыта.
3) Сложность использования вашего и нашего решений не отличается. Хотя я по прежнему не понимаю как у вас решение работает, т.к. на вопрос заданный выше вы не ответили.
4) Утверждение не верное, там и так корректный бинарник. Причем утверждение основано на противопоставлении, а оно не обязательно должно быть.
И вот как итог уже: зачем огород городить? ради этих 4 пунктов, которые практически не имеют под собой оснований?
К слову, основное преимущество моего подхода — это поддержка Git.
То есть вы на полном серьезе строите структуру проекта под инструмент? :)
Ну так я о том и говорю — результатом работы сейчас становится красивый репозиторий, вместо кода.
У нас во главе угла проект, а не инструменты, и по этому мы смотрим на инструменты удовлетворящие наши нужды, а не нужды под инструмент подстраиваем.
Ну отлично, вместо аргументов пошло «сам дурак». :)
Я обозначил конкретные задачи и их решения. Объяснил, почему ваши доводы не актуальны… Странный у вас способ ведения диалога.
Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Где тут сказано что она не предназначена для работы с бинарниками и контентом?
По поводу скорости:
У меня нет опыта работы с 100 гиговыи репами… Наш 8 гиговый обрабатывается секунд 5. Намека на тормоза нет. Судя по инету — SVN начинает тормозить на репах от 20 гигов. 20 гигов даже с учетом контента надо постараться нафигачить. :)
Чистота — вопрос спорный. От того что в репозитории появилось несколько новы каталогов он грязнее не стал.
2. Простые и быстрые коммиты без головной боли.
Неужели добавление бинарника в репу на это как-то влияет? :)))
3. Художникам только кнопки нажимать надо.
А в приведенном у меня примере они еще что-то должны нажимать?
4. Бинарники обновляются только при успешной сборке.
Аналогично и при хранении в SVN. Там лежит всегда работающий бинарник. В условиях простых тулз он еще всегда и самый актуальный, потому что собран самим программистом. При этом ничего не мешает добавить файлик, если уж очень хочется в ежедневную сборку. Правда смысла не видно.
Так что повторюсь:
Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
Выше перечисленные пункты более чем спорные и ИМХО недостаточны чтобы огород городить.
CI не нужен, и вообще всё слишком сложно, всегда одного SVN хватало.
Сервер непрерывной интеграции конечно же нужен. Для основного проекта. Задача сервера в первую очередь обеспечить процесс тестирования проекта. Тулзы нафига в него пихать? Они меняются не так часто, полномасштабное тестирование им не нужно. Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
То есть у вас каждый инструмент — это ровно один исполняемый файл? Ни динамических библиотек, ни конфигов, ни прочих зависимостей?
Библиотеки как правило не меняются, а значит при commite не светятся.
Конфиги никто со времен висты не хранит рядом с бинарниками — они все уникальны для каждого пользователя и хранятся в Май доках.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
бинарники самые актуальные какие только могут быть, потому что залиты вместе с исходниками. то есть строгое соответствие.
А как художникам тулзы тянуть?
И зачем вообще заставлять художников отдельно тянуть тулзы?
Они в начале рабочего дня делают Update и имеют полностью актуальную версию проекта.
Я коммичу сорцы, а мне в диалоге тонна мусора из бинарников, чёрт ногу сломит.
А у меня тонны мусора нет, потому что весь мусор изначально в игнор листе.
А зачем?
Один из примеров использования externals:
делаем проект, в нем отдельный каталог tools, которым пользуются художники, моделлеры и проче артисты.
Сами по себе тулзы не являются частью проекта и используется в нескольких проектах, поэтому подключены как externals.
При этмо репозиторий с тулзами содержит как исходники, так и бинарники. И вот именно каталог bin подключен в виде externals к проекту.
Зачем мне тут несколько отдельных репозиториев?
externals пока по ощущениям самые удобные в svn.
как раз планировал уйти с svn на git или hg, в надежде получить более контролируемые externals, но там оказалось все еще хуже.
так что мирюсь с externals не привязанными к ревизии, зато они нормально работают.
VCS не делает проект плохим.
Но если выясняется, что без некоторых «фишек» VCS разработка проекта стопорится — это показатель его плохости.
Повторюсь: не причина, а показатель.
В этом случае я использую SVN.
Речь не о том, что контроль версий не нужен.
Речь о том, что проект, в котором приходится отдельно серьезно прорабатывать структуру репозитория и правила коммитов, проект, в котором от VCS требуется больше чем Commit/Update/Diff — плохой проект. И решать проблемы надо не накручиванием функционала VCS, а пересмотром структуры проекта.
оффлайн репозитории с постоянными коммитами никак эту проблему не решают.
ну и в целом, либо у вас работа этих 700 человек глобально не пересекалась, либо были огромные проблемы с архитектурой.
Гляжу на сложность современных систем контроля версий…
Слушаю фразы в духе «У меня все время открыт Repository Explorer, я в нем работаю»…
И все сильнее погружаюсь в ощущение, что VCS из инструмента превратились в проблему…
Наверно, это очень удобно на каждый чих делать коммиты… Но моя работа, как программиста, писать код, а не следить за ветвями, с кучей мелких коммитов…
Результатом моей работы является код, а не репозиторий.
Поэтому давно и надолго — SVN и коммиты только в ключевых точках.
В современном мире проекты устаревают и умирают раньше, чем загибаются.
Я сам вел проект, который в итоге свалился в говнокод… Ну и ок. Он прожил 8 лет, принес дофига бабла, а сейчас на его базе делается новый.
Сейчас в 99% случает нет смысла делать long life код.
Назвал.
И там вопрос, кстати, было бы интересно услышать как это делается у вас.
Это не правда.
В кратце:
1) Скорость не страдает, термин «чистота» не раскрыт.
Где здесь «нам так удобнее»?
2) Сложность коммита не раскрыта.
3) Сложность использования вашего и нашего решений не отличается. Хотя я по прежнему не понимаю как у вас решение работает, т.к. на вопрос заданный выше вы не ответили.
4) Утверждение не верное, там и так корректный бинарник. Причем утверждение основано на противопоставлении, а оно не обязательно должно быть.
И вот как итог уже: зачем огород городить? ради этих 4 пунктов, которые практически не имеют под собой оснований?
То есть вы на полном серьезе строите структуру проекта под инструмент? :)
Ну так я о том и говорю — результатом работы сейчас становится красивый репозиторий, вместо кода.
У нас во главе угла проект, а не инструменты, и по этому мы смотрим на инструменты удовлетворящие наши нужды, а не нужды под инструмент подстраиваем.
Я обозначил конкретные задачи и их решения. Объяснил, почему ваши доводы не актуальны… Странный у вас способ ведения диалога.
Где тут сказано что она не предназначена для работы с бинарниками и контентом?
На ютубе видео с пометкой GoPro выглядят гораздо четче
P.S.
Качество в настройках ролика 720p
Ну ок, давайте по пунктам:
По поводу скорости:
У меня нет опыта работы с 100 гиговыи репами… Наш 8 гиговый обрабатывается секунд 5. Намека на тормоза нет. Судя по инету — SVN начинает тормозить на репах от 20 гигов. 20 гигов даже с учетом контента надо постараться нафигачить. :)
Чистота — вопрос спорный. От того что в репозитории появилось несколько новы каталогов он грязнее не стал.
Неужели добавление бинарника в репу на это как-то влияет? :)))
А в приведенном у меня примере они еще что-то должны нажимать?
Аналогично и при хранении в SVN. Там лежит всегда работающий бинарник. В условиях простых тулз он еще всегда и самый актуальный, потому что собран самим программистом. При этом ничего не мешает добавить файлик, если уж очень хочется в ежедневную сборку. Правда смысла не видно.
Так что повторюсь:
Выше перечисленные пункты более чем спорные и ИМХО недостаточны чтобы огород городить.
Сервер непрерывной интеграции конечно же нужен. Для основного проекта. Задача сервера в первую очередь обеспечить процесс тестирования проекта. Тулзы нафига в него пихать? Они меняются не так часто, полномасштабное тестирование им не нужно. Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
Библиотеки как правило не меняются, а значит при commite не светятся.
Конфиги никто со времен висты не хранит рядом с бинарниками — они все уникальны для каждого пользователя и хранятся в Май доках.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
А как художникам тулзы тянуть?
И зачем вообще заставлять художников отдельно тянуть тулзы?
Они в начале рабочего дня делают Update и имеют полностью актуальную версию проекта.
А у меня тонны мусора нет, потому что весь мусор изначально в игнор листе.
Один из примеров использования externals:
делаем проект, в нем отдельный каталог tools, которым пользуются художники, моделлеры и проче артисты.
Сами по себе тулзы не являются частью проекта и используется в нескольких проектах, поэтому подключены как externals.
При этмо репозиторий с тулзами содержит как исходники, так и бинарники. И вот именно каталог bin подключен в виде externals к проекту.
Зачем мне тут несколько отдельных репозиториев?
Эх, какой я наивный. :(
как раз планировал уйти с svn на git или hg, в надежде получить более контролируемые externals, но там оказалось все еще хуже.
так что мирюсь с externals не привязанными к ревизии, зато они нормально работают.
Но если выясняется, что без некоторых «фишек» VCS разработка проекта стопорится — это показатель его плохости.
Повторюсь: не причина, а показатель.
Речь не о том, что контроль версий не нужен.
Речь о том, что проект, в котором приходится отдельно серьезно прорабатывать структуру репозитория и правила коммитов, проект, в котором от VCS требуется больше чем Commit/Update/Diff — плохой проект. И решать проблемы надо не накручиванием функционала VCS, а пересмотром структуры проекта.
ну и в целом, либо у вас работа этих 700 человек глобально не пересекалась, либо были огромные проблемы с архитектурой.
Слушаю фразы в духе «У меня все время открыт Repository Explorer, я в нем работаю»…
И все сильнее погружаюсь в ощущение, что VCS из инструмента превратились в проблему…
Наверно, это очень удобно на каждый чих делать коммиты… Но моя работа, как программиста, писать код, а не следить за ветвями, с кучей мелких коммитов…
Результатом моей работы является код, а не репозиторий.
Поэтому давно и надолго — SVN и коммиты только в ключевых точках.
По моим впечатлениям, объем кода для интеграции примерно такой же.
sol-online.org/index.php?content=info&project=tactics
map.baidu.com
Отдельного внимания в них заслуживает режим изометрии:
habrahabr.ru/post/115107/
Заблокируют — тогда уж выходить через прокси и сливать дамп.
А сейчас — просто трата времени.
Речь о тенденции. Странно, что это надо объяснять.
Я сам вел проект, который в итоге свалился в говнокод… Ну и ок. Он прожил 8 лет, принес дофига бабла, а сейчас на его базе делается новый.
Сейчас в 99% случает нет смысла делать long life код.