Алексей Шумкин: так если использовать alias-ы - то и submodule можно юзать. Одной из главных претензий в адрес submodule была заявлена сложность манипуляций с ним в смысле большого количества команд для выполнения простых действий. Если те же проблемы у subtree - в этом смысле особой разницы нету.
Не поверите - я как раз пытаюсь написать свою систему решения зависимостей (обобщённую, с интегрированной в неё системой контроля версий ресурсов для сборки и билд-системой). Вопрос задавал как раз для приведения в порядок этого проекта.
Возможно, для C++ есто что-то свое, но я далек от этого мира
В С++ нет модулей, поэтому там труднее с этим. В плюсах есть темплейты, что делает работу с зависимостями ещё труднее. Из того, что есть и что я немного пробовал - есть biicode, который работает на уровне исходников - читает иклуды и грузит файлы по соответствующим путям в глобальном репозитории. Подход, кстати, весьма неплох в своей простоте - отчасти его себе притырил.
П.С.: Спасибо за указание на Ivy - судя по всему, штука близкая к тому, что я делаю. Почитаю и, возможно, даже для себя использую.
Вообще великолепно. Смотрю уже следующий вопрос - изоляция части проекта в отдельную репу, чтобы дальше subtree на части его побить, и натыкаюсь на комментарий (edited Aug 28 '14 at 19:51) с пометкой в updated-секци:
"This process is so common, that the git team made it much simpler with a new tool, git subtree"
Andy_U: но понял, что буду, скорее всего, subtree использовать - не смотря на то, что submodule (насколько я успел его понять) мне кажется более правильным идеологически для конкретно моего случая; всё испортили комментарии по поводу ужасов бранчевания при использовании submodule.
Andy_U: та я просто немного впечатлён самой концепцией. Минимум шесть лет существует два параллельных механизма (причём, на мой взгляд, по одному из весьма важных вопросов), которые не были приведены к единому виду. Причём в такой штуке, как одна из основных мировых систем контроля версий.
Andy_U: продолжаю изучать вопрос. Вот ещё симптомотичная статья, как по мне. Была написана в 2013-ом году. В самой статье автор жутко ругает submodule. Его вывод: "Now, I think that is [subtree] much better than using submodules and a lot less invasive to my repo."
Статья интересна развитием истории в обсуждениях. subtree некоторые, ругают (1 феврая 2013), некоторые хвалят (упоминается Pro Git book, их которой, по словам автора, следует что subtree выглядит лучше, коммент от второго февраля 2013 года).
Через полгода автор статьи отвечает (26 августа 2013 года) на вопрос по поводу subtree: да, спустя полгода он по-прежнему любит subtree.
Дальше самое странное. Продолжение обсуждения, март 2015 года, упоминание subtree как деприкейтнутой технологии и комментарий по-прежнему ругательный по отношение к submodule: "I understand subtrees were deprecated in favor of submodules, but I still feel that submodules have various drawbacks"
Кстати, выше, ещё один комментарий: "After all, subtree merge was invented merely as a short-term hack to serve as a stop gap measure until submodule support becomes mature". То есть subtree была придумана как хак.
Наконец, последний комментарий в обсуждении, середина октября 2015 года. Subtree по-прежнему круче по мнению комментатора: "OTOH submodules are very brittle, so I'm reluctant to use them as well".
В сухом остатке главные претензии к submodule всё те же: хреново бранчить, форкать и вообще делать какие-либо телодвижения по работе с версиями проекта, в котором используется submodule.
Но при этом механизм subtree, судя по всему, был временным решением, которое оказалось круче основного.
П.С.: Самое интересное, по subtree таки действительно нет статьи в официальной доке (git subtree help не проходит в моей версии гита). Вот одна из первых ссылок в гугл по запосу git subtree documentation, и это не та дока, что для всех прочих команд в svn - это просто отдельный от хэлп по теме как можно использовать subtree в проектах.
Возникает ощущение, словно subtree - какая-то замечательная футуристическая технология, гонимая тайными масонами среди разработчиков git-а.
Andy_U: а вы не встречали официальной информации от авторов git, которая говорила бы о механизме submodule как об устаревшем? Я попробовал поискать только что - не вышло найти, только несколько ругательных статей, рассказывающих почему submodule такая неудобная штука.
Я что-то запутался. Давайте разберёмся по картинке. Вот есть три репозитория. Один из них (третий, our repo) это наш репозиторий. В какой-то момент мы решили привязать к нему модуль, у которого есть свой репозиторий (второй репозиторий, module repo). В коммите, который обозначен маркером (1) мы выполнили его связывание с нашим (пока опустим конкретный способ связывания - subtree или submodule). При существует другой проект (первый, other repo, и такой проект может быть не один), который также использует модуль. При этом что наш проект, что сторонний может в течение разных промежутков времени "сидеть" на определённой версии модуля, и обновляться в нужные для этих проектов моменты времени (коммиты, выполняющие изменение версии зависимости: маркеры (3) и (4) ).
Картинка
Теперь по поводу моих рассуждений. Я выдвинул предположения о следующих основых юзкейсах для использования рассматриваемых механизмов:
Для submodule:
- Использование в ситуации, когда module repo не находится в нашем прямом распоряжении, это сторонний репозиторий, разрабатываемый другой конторой/командой разработчиков. В этом случае нам всё равно какие изменения происходят в этом модуле, нас интересуют вполне конкретные версии этого репо. Мы не хотим чтобы новые снапшоты модуля мусорили историю нашего репозитория - это сторонний, скорее всего законченный проект вне нашей области ответственности, который мы не трогаем - максимум пул-реквесты владельцам репо с пожеланиями наших изменений.
Для subtree:
- Использование для разработки внутри конторы. Какие-то внутренние модули или даже просто шареные файлы, единые для нескольких внутренних проектов, которые можно обсудить с человеком за стенкой (то, что вы описали как "есть проблемы - обсуждайте с разработчиком").
- Использование для open source, где происходит активная разработка большой командой людей. В этом смысле subtree выступает чем-то вроде обычной ветки, но расшаренной между несколькими репозиториями для удобства.
Ясно что в обоих случаях перед переходом на новую версию моделя в основном проекте (superpoject) будет уход в ветку для внесения изменений в связи с переходом. Но тут речь идёт, скорее, об идеологии использования.
П.С.: Сегодня читал документацию, и там написано что-то, как мне показалось, намекающее на подобное разграничение областей использования subtree и submodule.
Цитата
If you want to merge the project histories and want to treat the aggregated whole as a single project from then on, you may want to add a remote for the other project and use the subtree merge strategy, instead of treating the other project as a submodule. Directories that come from both projects can be cloned and checked out as a whole if you choose to go that route
В случае перемещения деструктор перемещённого объекта в общем случае ничего не должен делать.
У меня деструктор ничего не делает. Он при этом не будет вызван?
copy elision
Справедливо... Хотя основной конструктор в этом случаи всё-таки будет вызван.
Короче, я понял - не стоит думать о таких тонких оптимизациях. Даже в случаи с математическими программами, где временных объектов-векторов могут быть тысячи не в создании объектов будет тонкое место.
Всё-таки есть проблема, которую я не очень понимаю как решить даже дублирующим рендером. Что если нам нужно рисовать разные меши? Для каждого типа меша (для каждой модели) придётся всё равно вызывать draw-команду? Это лучше чем для каждого объекта вызывать, но всё равно - на сцене могут быть представлены сотни разных моделей, а хотелось бы свести количество draw-вызовов до минимума.
Возможно, есть способ в начале перечислить набор мешей, которые мы хотим отрисовать, а потом отправить их рисоваться всей кучей через одну draw-команду (и, соответственно, позволить openGL максимально параллельно организовать отрисовку) ?
Спасибо. Отличный курс, покрывающий почти все интересующие меня темы! Буду его изучать тогда. Исходя из этих уроков, ответы на мой вопрос будут следующие, как я понял:
Спасибо за описание работы abbr - давно искал тег с таким эффектом. Спойлеры использовал - как на меня, они, скорее, подходят чтобы прятать опциональную либо раскрываемую дальше информацию в статье.
По поводу "тестовых хабов" - я имел в виду не модератора, а сообщество. Такой себе бета-тест статьи. Но такого тоже нет, насколько я понял, так что буду вычитывать статью в кругу знакомых и публиковать начисто.
Тут вот проблема... Область - разбор текстов. Я реализую разбор с помощью недетерменированных конечных автоматов. Если для конечных автоматов терминология ещё есть, то для реализаций конечных автоматов (с учётом того, что я кое-какие изменения под свою задачу вносил) её нужно новую придумывать всё равно.
А она именно так работает? Если в статье какие-нибудь глупости будут мне не сольют карму за них и не опустят статью на самое дно, откуда про неё ничего не узнают?
