Cкpипaч, пророк (31.01.2022 15:58, просмотров: 153) ответил VLLV на Это точно тупик. Сейчас образовались два таких пакета для приборов
с разными интерфейсами, и 50 процентов времени уходит на
копирование изменений из одного пакета в другой :(... но не любой ценой.
-
- Проблему "общего кода" решает система контроля версий. В каждом
проекте используется своя проверенная с данным проектом версия
библиотеки. Исправление ошибок и доработка библиотеки выполняется
при этом в "одном экземпляре". А добавить эти исправления в старый
проект можешь по своему желанию. il-2(1 знак., 31.01.2022 16:08, ссылка)
- У каждого свой путь. Можно "контроля версий", а можно просто проектные папки. Которые тоже запихнуть под контроль версий, но в виде строго отдельных проектов. Cкpипaч(239 знак., 31.01.2022 16:16)
- Просто проблема перейдет в другую плоскость - какую ревизию
библиотеки использовать ? - VLLV(31.01.2022 16:13)
- Расслабься, умные люди уже за тебя все придумали :-) В Mercurial
эта штука называется subrepositories, в git - submodules(могу
соврать - поправьте). Нормальная система контроля версий сама
следит, какая версия библиотеки (субрепозитория) будет привязана к
текущему коммиту основного репозитория проекта. Так что на бумажке
ничего не прийдется записывать :-) - il-2(31.01.2022 16:24)
- Работаю с external svn, про бумажку знаю :) Смотри, имеется два
проекта. В одном проекте нужно поменять общую библиотеку, в другом
не обязательно, не меняем. А потом вдруг нужно в той же библиотеке
поменять для проекта, в котором не менялось. Выбор: то ли дробить
библиотеки, то ли вводить ненужные изменения. В максиме Скрипача о
раздельных проектах есть рациональное зерно, только у него проекты
трудоемкостью не 5 человеко-лет. - VLLV(31.01.2022 17:07)
- Библиотеки (субрепозитории) у каждого проекта свои (как любит
Скрипач). Но внешний репозиторий библиотек у всех проектов один.
Через него и идет обмен. il-2(890 знак., 01.02.2022 05:56)
- Вот на этом: "не забывать обновлять" и надо отбросить этот способ -
редко не забывает. - symbions(01.02.2022 08:18)
- Я использую оба способа. В старых проектах - первый (т.к. там
исторически либы были скопированы в каталог проекта, а с недавнего
времени делаю ссылки в новых проектах. Дискомфорта не наблюдаю.
Может потому, что при переключении на другой проект, первое и
естественное движение - это глянуть в его репозиторий, чтобы узнать
какой коммит в данный момент в рабочей директории. - il-2(02.02.2022 05:49)
- Нет. ПРосто Вы очень собранный и самодисциплинированный человек. Тут в институте ввели цифровую подпись, на каждом собрании говорили, что имя файла после подписывания менять нельзя, иначе файл не откроется. И что? Как минимум 30% вторых подписантов подписывают файл не "подписать_отчёт.odt.p2s" а файл "подписать_отчёт.odt (1)" - а автоматической системе учёта потом мозги сносит. И у нас в отделе (бывшем, правда) из 5 программистов, трое будут забывать всегда, 1 - через раз, symbions(97 знак., 02.02.2022 08:41)
- Я использую оба способа. В старых проектах - первый (т.к. там
исторически либы были скопированы в каталог проекта, а с недавнего
времени делаю ссылки в новых проектах. Дискомфорта не наблюдаю.
Может потому, что при переключении на другой проект, первое и
естественное движение - это глянуть в его репозиторий, чтобы узнать
какой коммит в данный момент в рабочей директории. - il-2(02.02.2022 05:49)
- Вот на этом: "не забывать обновлять" и надо отбросить этот способ -
редко не забывает. - symbions(01.02.2022 08:18)
- Библиотеки (субрепозитории) у каждого проекта свои (как любит
Скрипач). Но внешний репозиторий библиотек у всех проектов один.
Через него и идет обмен. il-2(890 знак., 01.02.2022 05:56)
- Работаю с external svn, про бумажку знаю :) Смотри, имеется два
проекта. В одном проекте нужно поменять общую библиотеку, в другом
не обязательно, не меняем. А потом вдруг нужно в той же библиотеке
поменять для проекта, в котором не менялось. Выбор: то ли дробить
библиотеки, то ли вводить ненужные изменения. В максиме Скрипача о
раздельных проектах есть рациональное зерно, только у него проекты
трудоемкостью не 5 человеко-лет. - VLLV(31.01.2022 17:07)
- В новый проект - самую свежую. В старый проект - ту, с которой оно
раньше работало. Если нужно перенести в старый проект фичи из
свежей ревизии - втыкаешь свежую ревизию и смотришь что получилось. - LightElf(31.01.2022 16:17)
- А когда "новый" с минимальными правками получается из сделанного
семь лет назад? - Cкpипaч(31.01.2022 16:29)
- На выбор. Можешь оставить старую, с которой заведомо работает. Можешь подтянуть новую и перетестировать проект, раз уж все равно в него залез. - LightElf(31.01.2022 17:03)
- В отдельной ветке. Главное - ты должен знать чего откуда растёт.
Знать а не помнить. Т.е. иметь возможность в любой момент проверить
этот факт одной командой. - =AlexD=(31.01.2022 16:31)
- Нет уж. Лучше сто независимых проектов. - Cкpипaч(31.01.2022 16:42)
- Да хоть миллион. Речь вообще не про проекты. - =AlexD=(31.01.2022 16:44)
- Нет уж. Лучше сто независимых проектов. - Cкpипaч(31.01.2022 16:42)
- А когда "новый" с минимальными правками получается из сделанного
семь лет назад? - Cкpипaч(31.01.2022 16:29)
- Расслабься, умные люди уже за тебя все придумали :-) В Mercurial
эта штука называется subrepositories, в git - submodules(могу
соврать - поправьте). Нормальная система контроля версий сама
следит, какая версия библиотеки (субрепозитория) будет привязана к
текущему коммиту основного репозитория проекта. Так что на бумажке
ничего не прийдется записывать :-) - il-2(31.01.2022 16:24)
- Да не тестируем мы ни хрена! :) - VLLV(31.01.2022 16:02)
- Мы - тоже! :) - Cкpипaч(31.01.2022 16:23)
- Проблему "общего кода" решает система контроля версий. В каждом
проекте используется своя проверенная с данным проектом версия
библиотеки. Исправление ошибок и доработка библиотеки выполняется
при этом в "одном экземпляре". А добавить эти исправления в старый
проект можешь по своему желанию. il-2(1 знак., 31.01.2022 16:08, ссылка)