Нарушение сборки на пару дней - PullRequest
Новая
       19

Нарушение сборки на пару дней

1 голос
/ 27 августа 2010

Я недавно отправил электронное письмо своим коллегам, объяснив, что мне нужно внести некоторые изменения в наше общее представление ClearCase, которое будет означать, что наш проект будет в некомпилируемом состоянии в течение дня или двух.

Один парень жалуется на это. Что я могу сделать, чтобы предотвратить его жалобу?

Ответы [ 5 ]

9 голосов
/ 27 августа 2010

Внесите изменения в отдельную ветку и возьмите на себя ответственность за объединение изменений, когда вы закончите.

Я, конечно, могу понять, почему ваш коллега может жаловаться на это - вы, по сути, мешаете ему / ей выполнять работу, которую они планировали сделать в противном случае.

2 голосов
/ 27 августа 2010

Вы можете предотвратить его жалобу, если не нарушит сборку!

Сборка - это не просто какой-то ночной процесс, который происходит где-то в углу, который никого не волнует - он происходит на каждая машина разработчиков каждый раз, когда они хотят что-то отладить или протестировать!

Если сборка не работает на сборочной машине, она ломается на каждой машине разработчика - Для разработчиков сборка должна быть священной , поскольку поврежденная сборка означает, что другие люди не могутвыполнять свою работу.

С точки зрения того, что вы можете сделать, чтобы ваши изменения не сломали сборку, многое зависит от того, что именно вы изменяете, однако некоторые общие предложения:

  • Внесите изменения в отдельную ветку и объедините их, как только они будут завершены
  • Избегайте внесения больших изменений и вместо этого разделите ваши изменения на множество мелких неразрывных коммитов.*
0 голосов
/ 27 августа 2010

Способ ClearCase справиться с такой ситуацией (которая может произойти, например, при выполнении длинного и сложного слияния):

  • сначала поставить метку для идентификации ситуации перед любыми изменениями
  • начать изменения

  • , если процесс занимает слишком много времени и другие пользователи затронуты (либо потому, что их динамические представления * немедленно * отражают * новые версии, либо потому, что им нужно обновить свой снимокили потому что вы используете то же представление, что возможно при динамическом просмотре), тогда:

    • по крайней мере прекратите совместное использование этого представления и создайте свой собственный : ifэто представление снимка, вы можете использовать ту же спецификацию конфигурации.Не проверяйте, пока он не скомпилируется снова
    • в идеале, создайте его со своей собственной веткой, начиная с метки : таким образом, вы можете сделать промежуточные проверки, а затем объединить их в конце.

Конфигурационная спецификация для использования вашей собственной ветки, начиная с метки, которую вы указали бы перед внесением любых опасных изменений, будет выглядеть так: 

    element * .../MyBranch LATEST
    element * MY_LABEL -mkbranch myBranch
    element /main/LATEST
0 голосов
/ 27 августа 2010

Если вы используете SVN, это должна быть простая ветвь.В противном случае вы, возможно, захотите рассмотреть операцию копирования / прошествия и объединить себя в конце.

Лично я считаю, что рассказывать другим, что их работа будет в некомпилируемом состоянии в течение нескольких дней, является возмутительным.По сути, вы говорите своим сверстникам о двух вещах.

  1. Ваши изменения намного важнее, чем их
  2. Вы не сможете работать пару дней.
0 голосов
/ 27 августа 2010

Или

  • Объясните ему, почему вы должны это сделать, и он поймет, если нет лучшего решения

или

  • Сделай лучшее решение

Edit:

Я не знаю, почему я получил отрицательный голос за это. По сути, я говорю, что вы не должны пытаться «помешать ему жаловаться». Либо он не понимает, почему то, что вы делаете, является лучшим решением, либо то, что вы делаете, не является лучшим решением. Просто подойдите и поговорите с парнем об этом и обсудите проблему, пока вы оба не согласитесь друг с другом.

Кто-то из вас прав, а кто-то не прав, я не говорю, что, мне не хватает информации.

...