У меня довольно редкая проблема с контролем источника. В примере здесь проблема возникла с Perforce, но я подозреваю, что одна и та же проблема будет иметь место со многими SCM, особенно с распределенными SCM.
Perforce поддерживает списки изменений (или изменения, если вы предпочитаете). Хэндэлисты поддерживают два общих обычаев:
-
Когда вы фиксируете список изменений, commit является атомарным, так что все файлы зафиксированы или нет. Это основная функция, о которой говорит большинство людей, когда ссылаются на списки изменений.
-
Perforce поддерживает несколько списков изменений. В основном, когда вы просматриваете файл, вы говорите ему, чей список изменений принадлежит. Итак, если вы работаете над новой функцией электронной почты, которая займёт месяцы работы и составит миллионы долларов, а кто-то из технической поддержки придет к вам с ошибкой, которая должна быть исправлена вчера, вам не нужно начинать с новая ветвь всего проекта. Вы можете просто проверить файл с ошибкой в новом списке изменений, устранить проблему, проверить новый список изменений и вернуться к реальной работе новой функции электронной почты, как будто ничего не произошло.
По большей части все отлично работает. Тем не менее, когда вы выполняете функцию электронной почты, вы делаете zillions изменений повсюду, особенно в main.h, и так бывает, что при работе над исправлением ошибок вы обнаруживаете, что крошечное изменение, которое вы должны сделать также находится в main.h. В списке изменений для новой функции уже есть файл main.h, поэтому вы не можете легко поместить его в список изменений для исправления ошибок.
Теперь, что вы делаете? У вас есть несколько вариантов:
-
Создайте новый clientpec. Клиентом в Perforce является список файлов/каталогов в депо и локальный пункт назначения, где все должно быть скопировано. Таким образом, вы можете создать вторую копию проекта без каких-либо изменений для функции электронной почты.
-
Сделайте выдумку. Создайте резервную копию измененной копии main.h и верните этот файл. Затем вы можете проверить main.h в списке изменений в bugfix. Вы исправляете ошибку, проверяете список изменений в bugfix, затем проверяете main.h в списке изменений электронной почты. Наконец, вы слейте все свои изменения из резервной копии, сделанной в начале.
-
Вы определяете, что все изменения, внесенные в main.h, не имеют побочных эффектов или зависимостей, поэтому просто переместите main.h в список изменений в bugfix, внесите изменения и проверьте их. Затем вы проверяете это снова в список изменений электронной почты. Очевидно, что существует два проблемы с этим подходом: во-первых, на самом деле могут быть побочные эффекты, которые вы не рассматривали, а во-вторых, вы испортили свою версию histoty.
Вариант 1, вероятно, самый чистый, но не всегда практичный. Проект, над которым я работал, имел миллионы строк кода и действительно сложный процесс сборки. Для настройки новой среды потребуется целый день, поэтому это было не очень практично для исправления ошибки на 5 минут.
Вариант 3 - это плохой вариант, но он самый быстрый, поэтому он может быть очень соблазнительным.
Это оставляет вариант 2, который я обычно использовал.
Есть ли у кого-нибудь лучшее решение?
Мои извинения за длительный вопрос, но я обнаружил в StackOverflow, что полностью продуманные вопросы дают лучшие ответы.
