Ну и постоянно создаваемые головы надоедают страшно. У нас запрещено их в пространсто пихать, поэтому
commit
приходится делать непосредственно перед push
. Привыкнуть, конечно, можно, но... Я тут на днях продолбал файл с изменениями в JDK 9, которые обычно прививал в JDK 8 командой patch
. Воспользовался командами export
и import
(вторая делает commit
), скомпилировал, протестировал, а запушить не дают, так как за это время меня уже кто-то опередил. Кучу времени на этом потерял...
Тут, как мне кажется, проблема на в самом меркуриале (который вполне себе годен; лучше бы у нас его использовали, кстати). Проблема, по крайней мере по твоему описанию, в CM-процессе, который у вас там сейчас существует.
ОтветитьУдалитьПроблема в том, что нет никакого процесса. Было просто сказано: теперь используем Mercurial вместо SCCS. И все балуются в меру своих сил. Есть, например, такая штука, как rebase, но у нас боятся её использовать, так как она может сделать merge совсем неочевидным способом.
УдалитьОтсутствие процесса - тоже процесс :) Это когда весь CM переложили на девелоперов. Всякий раз, когда что-то сильно ломается, девелоперы сами собираются и решают, что и как делать дальше. Самоорганизация, да:)
УдалитьСерьёзный процесс был в Motorola Mobile Devices. О нём могу при случае рассказать. В двух словах так: в MMD у девелопера вообще не болела голова ни о ребейзак, ни о мёржах, ни о всём таком. Простейшие правила работы с кодом, а всё остальное делала CM-команда и тестеры.
УдалитьВ Motorola Networks было сильно попроще, но всё равно жить можно. Сейчас проще некуда, но как-то договорились в итоге, есть минимально необходимый CM, живём пока без серьёзных проблем. По крайней мере, фризить транк не приходится по причине того, что какой-то коммит всё развалил насовсем.
У нас тоже есть похожая команда, которая вливает все изменения из child постранств в master. Чтобы облегчить их работу и не фризить транк, установлен серверный запрет на создание голов, поэтому следить за этим приходится нам.
Удалить