| Снегопат https://snegopat.ru/forum/ |
|
| А как вы организовываете работу с внешними обработками(CVS)? https://snegopat.ru/forum/viewtopic.php?f=3&t=302 |
Страница 1 из 1 |
| Автор: | Kir [ 03 дек 2012, 11:09 ] |
| Заголовок сообщения: | А как вы организовываете работу с внешними обработками(CVS)? |
А как вы организовываете работу с внешними обработками/отчетами? Один репозиторий на все, или новый на каждую обработку? Сразу прошу прощения за изобретение велосипеда, и за дилетантский мб подход. Но так как благодаря Евгению Сосне и другим разработчикам появился удобный встроенный механизм в скрипте "Внешние файлы", хочется упорядочить свою работу. Хочется организовать работу с двумя ветками, разработка и назовем релиз (та версия которую передал во внешнее тестирование или передал клиенту). Возможно стоит разделить тестирование и релиз, пока не знаю. При первом помещении описываю назначение обработки, затем коммиты с изменениями. Когда реализовал то что нужно на данный момент, отладил - переношу изменения в релизную ветку. Сделал копию (средствами скрипта с указанием даты и времени) и отправил кому надо. Вот... правильно я понимаю, что fossil merge делается для всего репозитория? Если начинаю работу над новой обработкой, то ее получается надо добавить сначала в ветку разработки? Из этого исхожу, что прозрачнее под каждую обработку свой репозиторий? |
|
| Автор: | sosnae [ 03 дек 2012, 11:13 ] |
| Заголовок сообщения: | Re: А как вы организовываете работу с внешними обработками? |
Kir писал(а): 2) не взлетает команда fossil ui Попробуй другой порт, может он у тебя чем-то занят? Или антивирус блокирует? Kir писал(а): 1) перестала выводиться текущая ветка в заголовке папки. Удалось повторить, подправлю на днях. Kir писал(а): Один репозиторий на все, или новый на каждую обработку? Для универсальных обработок, ирМобильные и т.д. отдельный репозитарий. Для клиента один репо. Внешние обработки отчеты разбиваю по папкам, вначале общий список обработок, если выделяются отчеты/обработки в отдельную группу или "Подсистему", тогда перемещаю в отдельную папку (fossil mv oldfilename newfilename для сохранения истории). Чаще всего структура папок у меня повторяет структуру справочника "Внешние обработки". Kir писал(а): Вот... правильно я понимаю, что fossil merge делается для всего репозитория? Для всей ветки/истории коммитов, но ты всегда можешь отказаться от merge некоторых файлов или сделать merge с веткой и указать определенный файл. Второй вариант надо проверить, я обычно пользуюсь fossil merge , он выводит мне 4 файла, делаю fossil undo Файл1, Файл2, Файл3 и у меня остается мердж только с одним файлом Файл4. У меня обычно 2-3 ветки, trunk - рабочий вариант, dev(на основе trunk) где веду разработку, ну и feature (на основе dev). Kir писал(а): Если начинаю работу над новой обработкой, то ее получается надо добавить сначала в ветку разработки? Да, обычно так. Kir писал(а): Из этого исхожу, что прозрачнее под каждую обработку свой репозиторий? Запутаешься, если много обработок и в различные идут коммиты, тогда создавай ветку "dev_УправлениеЗакупками", "dev_Логистика" , "dev_Инкассация" и т.д. Тогда сможешь всегда смержить только необходимый набор файлов и в теории конфликтов не часто будет.
|
|
| Автор: | kuntashov [ 03 дек 2012, 11:24 ] |
| Заголовок сообщения: | Re: А как вы организовываете работу с внешними обработками(C |
Общий подход - "один проект - один репозитарий". И тут просто надо решить, насколько отдельная обработка является "самостоятельным проектом". Чаще это не так, в нашей деятельности обычно "Один проект - одна конфигурация [конкретного клиента]", плюс все обработки вокруг нее. Поэтому обработки для одного клиента я бы держал в одном репо. |
|
| Автор: | Kir [ 03 дек 2012, 11:49 ] |
| Заголовок сообщения: | Re: А как вы организовываете работу с внешними обработками(C |
Спасибо! А после команды fossil undo из красивого графа тоже ветвь перехода стирается или рисуется следующая? =) Попробую покапать в сторону merge отдельного файла. Разделение веток по назначению(подсистеме) немного смущает тем, что если не доведу до рабочего состояния и отложу на когда нить потом, то простым поиском, когда ветка переключена на основную, я эту заготовку просто не найду. Когда под каждую обработку будет выделяется свой репозиторий, то начальная версия будет в ветке trunk, соответственно физически на диске будет хоть какая версия вне зависимости от активной ветки. Правда можно наверно при создании новой обработки в DEV сразу перенести ее и в trunk ветвь и добиться того же результата. |
|
| Автор: | sosnae [ 03 дек 2012, 12:03 ] |
| Заголовок сообщения: | Re: А как вы организовываете работу с внешними обработками(C |
1. Добавляешь новый файл в trunk, переключаешься в dev и делаешь merge с trunk, в теории у тебя конфликтов не будет и в dev попадет только новый файл. 2. Добавляешь новый файл в dev , переключаешься в trunk и merge с dev только этот файл. Думаю для линейности истории, лучше использовать первый вариант. Kir писал(а): А после команды fossil undo из красивого графа тоже ветвь перехода стирается или рисуется следующая? =) Что закоммитишь, то и будет в графе отображаться. После undo и merge одного файла, будет отображаться merge только этого файла и все. Можешь в ui смотреть timeline с кнопочкой "Показывать файлы" и будет видно какие файлы зашли, а какие нет.
|
|
| Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|