Мне хочется найти самый простой способ для решения сабжа?
Хотелось бы упростить свою работу с Mercurial, а пока она выглядит так:
1) hg clone <repositary-url> my-work
2) Копирую my-work в my-work-public
3) произвожу все магические действия с кодом в папке my-work
4) Затем начинаю отсматривать комиты от первого после клонирования к последнему. Попутно когда делаю hg up <ревизия> я мержу папки my-work и my-work-public с помощью WinMerge
5) Затем делаю hg push из my-work-public
подробнее:
Когда я веду работу с кодом, то какие-то комиты ломают сборку, но они мне нужны чтобы не запутаться что же я делал вообще. Но перед отправкой в репозитарий нужно создать набор комитов, которые не ломают сборку, для этого я использую WinMerge. Откатываясь на нужную мне ревизию в my-work, я могу затем смержить папку и сделать очередной hg ci -m "" в my-work-public, но уже не ломающий.
Мне кажется этот процесс можно упростить, но читая доку «Глава 12. Управление изменениями с Mercurial Queues» думаю что это все-таки будет тоже излишне громоздко. Есть ли способ еще проще чем MQ?
P.S.:
Возможно сумбурно написал, хоть и старался по-лучше, если что спрашивайте уточняющие :)
То что я спрашиваю в Git решается через интерактивное rebase. Мне нужно это же но для Mercurial, при этом не просто какие-то комиты принять, а какие-то нет но и во время принятия указать новый тип сообщения
Кажется есть кое что ) RebaseExtension. Теперь возникает вопрос: А какие еще есть способы работы? Мы же программеры знаем, что, как правило, задачу можно решить разными способами и не редко их больше двух!
Нет. Бранчи тут не помогут. Бранчи это история сложных процессов. К примеру по созданию фичи, правки сложного бага и др. действий. Основное правило любой системы контроля версий это — ни один комит не имеет права ломать сборку!
А я же описываю свой текущий внутренний процесс, когда я комичу даже «ломающие» комиты.
К примеру я знаю что я сейчас пойду спать и понимаю, что если я оставлю все исходники в этом состоянии то утром возможно что-то не пойму и чтото сделаю не так. Тогда принимаю решение «сохраниться» т.е. сделать более менее логический шаг и закомитить. Примером такого логического шага может быть «удаление интерфейса, т.е. чистого базового класса у которого лишь чистые вирт.функции» и я это комичу. Придя утром по логу hg log я могу понять, что сейчас мне надо удалять потомки. Но это ломает сборку и код!
Это похоже на работу методов класса, внутри любого метода инварианты могут нарушаться, но вот за пределами работы метода объект обязан быть в рабочем состоянии и не важно что произошло, толи брошено исключение, толи завершена работа метода, толи еще что-то.
Про п.2:
Потому что в этом состоянии папки находятся в одинаковом состоянии после клонирования репозитарии.
Одна папка для того чтобы из нее потом сделать hg push она для публикации, а вторая для «черновой» работы. Вся работа ведется в черновой папке. Черновая папка может содержать, как правило содержит, «ломающие» сборку комиты. А после завершения работ как раз и начинаю перенесения работы из черновика в папку для публикации. Делаю я это откатом на каждый комит, его просмотром, возможно откачусь на след. комит(ы) в черновой папке и сведения до такого состояния чтобы полученные изменения привели к комиту не ломающему сборку и после этого применяя WinMerge между двумя папками черновой и для публикации делаю hg ci -m уже в папке для публикации.
Сейчас понятней? )
Вы можете при каждом новом классе создавать ветку — ничего этому не мешает и никак не противоречит. Зато вы будете видить всю историю разработке класса, и проснувшись утром — поймете, что делали эти изменения конкретно с этим классом
Я описывал ситуацию с удалением. Как бы Вы поступили в этой ситуации? Т.е. прям сейчас Вас клонит спать\зовет жена погулять с ребенком\шеф обсудить индексацию зарплаты\друг у него что-то не комиллируется.
Опишу задачу еще раз: Вам прямо сейчас нужно оторваться, а процесс не завершено что вы сделаете в случае когда нужно удалить интерфейс, т.е. базовый класс с чистыми виртуальными методами?
Мои предположения что вы можете сделать:
* Записать на обычный бумажный листочек(у меня вечно со стола что-то пропадает, то жена порядок наведет, то уборщица на работе);
* Просто взять и удалить и оставить папку в том состоянии что есть. Надеясь на то что когда придете сразу же поймете что Вы в прошлый раз делали(У меня память не такая, постоянно забываю);
* Записать в todo-комментарий или прям в todo-менеджер(вечно забываю поглядеть в todo, никак в привычку не переводу это занятие).
ну сделали вы изменение, которое ломает сборку, но вы же об этом знаете. если вы закоммитите его в вашу ветку (на которой никто кроме вас билд собирать не будет) и на следующий день прочитав комментарий к последнему коммиту вы поймёте что делать дальше. на то она и ваша development-ветка, чтобы трекать изменения. И по-моему основное правило адекватных систем контроля версий (не ClearCase например) — это не «ни один комит не имеет права ломать сборку», а «один коммит — одно изменение», этакая атомарность коммитов.
Опять таки, папки копировать тоже не обязательно. Сделай две ветки. Одну для «грязного девелопмента», а вторую для стабильных, законченных изменений.
>>Одну для «грязного девелопмента», а вторую для стабильных, законченных изменений.
Публикация «грязных» комитов на паблик не просто не рекомендуется, за это надо сразу руки отрывать!
>> это не «ни один комит не имеет права ломать сборку», а «один коммит — одно изменение», этакая атомарность коммитов.
И вот тут ты Вы правы, Но не добавили что этот комит обязательно должен быть рабочим, в любом случае!
От работоспособности комита зависит дальнейшее использование. К примеру как Вы представляете себе работоспособность команды hg bitsect при комитах ломающих сборку?
что значит «в паблик»? если это ваша локальная ветка для разработки, то это ничего не испортит. в конце концов вы можете тэг добавлять что на данном коммите билд не собирается, но это опять-таки только для себя. и как выше заметил OnYourLips не обязательно на ВСЕХ ветках и ВСЕХ коммитах в них билд должен собираться.
>>что значит «в паблик»?
Вы не внимательно читали сам вопрос. О том что такое для меня я указал в посте своего вопроса! «в паблик» для меня это папка из которой в последствии применяется команда 'hg push'. Об этом п.5. Для тех кто этого не понял, еще раз пояснил см. мои комментарии. В виду того что все комиты в этой папке попадают в репозитарий куда я «проталкиваю» их и они становятся видимыми другим участникам имеющим к этому репозитарию куда протолкнул.
>>не обязательно на ВСЕХ ветках и ВСЕХ коммитах в них билд должен собираться.
Если эти ветки доступны участникам проекта, то абсолютно любой комит обязан быть «рабочим», т.е. не ломать сборку! К примеру в open-source проекта за этим строго следят мантейнеры. Очень хорошо помню свой первый комит на github-е, да, он ломал сборку только в одном комите. Но даже за него мне высказали «man git», а ведь могли объяснить где находится озерно Нахой в латинской америке и это было бы справедливо.
OnYourLips
>>Есть мнение, что это распространяется только на мастер, но не на бранчи
Нет. На любой бранч! Не важно какой он главный или по правке бага или еще для какой работы. Все эксперименты ведутся на компах участников проекта и только. В репозитарии должно быть исключительно работающее решение. Любой бранч это не только история, но и возможный инструмент отладки. К примеру с помощью bisect можно вычислить где появилась бага. Это даст любому разработчику в проекте возможность быстро получить среду по отладке кода. Что будет если кто-то залил ломающий сборку код? Это приведет к тому что разработчик перед правкой бага должен сначала пофиксить сборку и только потом уже заняться делом. Для чего ему спрашивается терять время если кто-то залил не работающий код?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
