SCRUM. У кого на работе считают, что используют?
Так зачем же ты тогда привел этот пример в качестве ошибки
во первых, хорошо запомнился. Во вторых, это смотря под каким углом посмотреть. Ну в третьих когда клиент говорит о проблемах, прежде всего думаешь об ошибке в программе.
Да и проблема действительно интересная. Я не знаю как ее решить когда дырки с двух сторон и нужно точно знать когда материал "закончится". Да даже как тест написать непонятно, нужно свой "таймер" выдумывать. Не знаю я Assert который работает "по времени".
Идея была еще в том, что как бы тесты не писали - подобную ситуацию предугадать довольно сложно. То бишь имея теоретическое 100% покрытие в программе остаются ошибки. Если ошибкой называть все, что работает не ожидаемым образом в любых ситуациях.
"Ошибка", которая стала известна до возникновения проблемы - это известный юз-кейс
так в том то и дело что это будет неизвестный юз-кейс
Prj2 должен быть внутри prj1
То бишь если не уставить субмодуль правильно, то весь проект2 попадет в репо проект1?
Я подумал, что это было решение для подобного распределения
c:\all\systemA\prj1 - локальный репо как проект1
c:\all\systemA\prj2 - локальный репо как проект2
c:\all\systemA\lib - локальный репо как библиотека к проекту х
Спасибо, хотя есть
https://git-scm.com/book/ru/v2/Инст�...
но это 17 страниц примеров, чтобы всего лишь понять принцип работы.
Пока удалось разобраться, что в репо субмодуля создается новая ветка для основного модуля и что основной модуль "полностью игнорирует" каталог субмодуля.
Следующее предложение тоже не совсем понятно. Если я изменил субмодуль из второго проекта, так что с первым уже не получится работать? Или это если в той же ветке субмодуля были "внешние изменения".
При работе с сабмодулями стоит помнить, что сабмодуль — это просто ссылка на конкретный коммит в другом репозитории. Если он изменился и нужно эти изменения смержить в основной репозиторий — нужно обновить содержимое сабмодуля и закоммитить измененный сабмодуль в основной репозиторий.
Ну и готовится к новым проблемам
http://alexanius-blog.blogspot.com/2012/04/git-submodule.h...
Если вы забудете опубликовать изменение подмодуля, другие не смогут клонировать репозиторий. - это уже серьезная проблема, если действительно так.
тоже похоже не без изъянов
Subtree takes ages to sync, maybe the way we are using is not optimal. Can't remember how long it took last time because no one wants to do it, or just leave it there overnight.
но есть с чем играться
https://medium.com/@porteneuve/mastering-git-subtrees-943d...
А кто то пробовал это под виндой?
https://github.com/ingydotnet/git-subrepo#readme
Что за команда "source"?
source /path/to/git-subrepo/.rc
Попробовал поиграться в репо из статьи
http://drive.delicious-insights.com/assets/git-subs-demo.z...
наткнулся на проблему(ошибка в гит?) которая в принципе все пользование субтрее перечеркивает. А именно - если сделать изменения в файле README.md plugin-а, а не как описано, то merge не происходит с main репо, получается конфликт двух "одинаковых файлов" один README.md plugin другой README.md main
Под никсами тоже самое происходит или нет?
Вроде концепт subtree и submodule стали несколько понятнее, но никак не могу найти преимуществ по сравнению с решением держать отдельные каталоги для каждого репо.
Что бы допустим, как в SVN можно было делать коммит сразу в несколько репо
Что за команда "source"?
Встроеная команда bash-а. Под мелкомягким cmd и повершелом работать, соответственно, не будет. Но вместе с git-ом идёт bash под именем git-bash. Вот в нём и под виндусями отработает.
Они добавляют в файл .bashrc строчку "source /path/to/git-subrepo/.rc" чтобы при каждом запуске шела выполнялись команды из /path/to/git-subrepo/.rc - добавляют каталог со своим расширением в PATH.
source filename [arguments]
Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, file names in PATHare used to find the directory containing filename. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if no file is found in PATH. If the sourcepath option to the shopt builtin command is turned off, the PATH is not searched. If any arguments are supplied, they become the positional parameters when filename is executed. Otherwise the positional parameters are unchanged. The return status is the status of the last command exited within the script (0 if no commands are executed), and false if filename is not found or cannot be read.