Лукас Уорд и я опубликовали статью « Модель контроля зрелости» почти три года назад. Я думал об этом в течение многих лет (в частности, уровень «PVC Dimensions» — уровень -1), и Лукас был отличным сотрудником, чтобы опубликовать его и воплотить идеи в жизнь. Конечно, она была вдохновлена моделью зрелости .
Эта статья является продолжением. В нем рассказывается о том, куда я хотел бы перейти из системы контроля версий, и переоценивается статья, которую мы с Лукасом ранее написали.
Вспомните запись в блоге за февраль 2010 года.
Обобщая ранее определенные уровни:
- Нет управления источником.
- Системы, которые удаленно хранят ревизии безопасно, но действительно работают лучше, если они находятся на том удаленном сервере, не слишком далеко, и персонал не слишком сильно наступает на пальцы друг друга с точки зрения одних и тех же исходных файлов, в основном избегая ветвления, потому что это дорого, и все медленно.
- Быстрее без атомных коммитов, многопользовательский режим терпимо.
- Еще быстрее + атомарные коммиты, возможности ветвления приличные, с отслеживанием точек слияния.
- Снова быстрее, лучше отслеживание точек слияния, элементарное слияние через переименование.
- Вся локально доступная история, дешевое локальное ветвление, слияние через переименование гладкое.
Уровень -1 был зарезервирован для инструмента, который настолько плох, что вообще ничего не использовалось.
Вещи, которые я хотел бы видеть в следующем поколении инструментов контроля версий
Семантическая разница / слияние.
Это намекает на уровень 6 в СКММ. Отличия могут быть слишком шумными, потому что инструменты не могут дать перерыв конкретным языкам. Рассмотрим приведенный в порядок JSON. Добавьте один элемент в список, это новая строка и измененная строка (запятая). Это не нужно так же невежественно, как:
Лучше, пожалуй, было бы так:
Несомненно, некоторые из продвинутых инструментов сравнения / слияния, таких как BeyondCompare , P4Merge и Kdiff3 , хорошо справляются с этой визуализацией, но требуется несколько усилий, чтобы подключить их к цепочке инструментов управления исходным кодом, когда встроенная технология слияния должна будьте такими же умными, но без необходимости побуждать людей к арбитражу при возникновении конфликтов.
Лукас говорит:
«Рост использования языков без статической типизации делает это еще более необходимым. В java, например, вероятно, что слияние будет обнаружено, по крайней мере, статической проверкой, даже если оно оставляет множество других возможных проблем. В javascript вы никогда не узнаете, если у вас нет очень хорошего тестирования. А тестирование Javascript-приложений все еще непросто, так что это хороший пример. Я не могу сосчитать, сколько раз меня облажал автоматизированный инструмент, манипулирующий кодом JS ».
Кроме того, инструмент управления исходным кодом на верхнем уровне также должен понимать «переименование метода» (и другие рефакторинги), а не последовательность добавления и удаления. Другой пример — «переупорядочение методов», когда один метод / функция перемещается ниже другого. Есть много других, которые ближе к нашему пониманию операций рефакторинга.
Это важно для слияния, конечно. Больше всего «слияния через переименование», но не только это. Мы хотим, чтобы слияния были автоматическими и безопасными, и это более вероятно при использовании более интеллектуальных инструментов. Объединение через переименование было главной чертой статьи 2010 года, и оно было связано с трехсторонним объединением, которое действительно хорошо понимало текст с разделителем возврата каретки. С командой, которая хочет безнаказанно проводить рефакторинг и иметь слияния, работающие между ветвями (или когда вы часто обновляете рабочую копию в своей локальной кассе), тогда инструмент контроля версий поймет, что вы сделали, и разрешит автоматическое слияние с помощью разрешения конфликтов. ключ. По крайней мере, это переместило бы планку конфликта.
Подзаголовок «программирования» называется «Преднамеренный». Преднамеренное программное обеспечение Чарла Симони (друга ThoughtWorks) решает некоторые из тех же проблем с нетекстовой концепцией «исходный», не разделенной CR. Я не говорю об этой технологии.
Синдикация с использованием Source-Control
Это существенно более умные субмодули или внешние компоненты и механизмы для совместной работы различных реализаций инструментов управления исходным кодом. В конце января я упомянул кое-что, что было бы полезно для локальных модификаций субмодуля, чтобы лучше синдицировать версионный контент и поддерживать расхождение. Конечно, это в значительной степени требует только я, но я думаю, что это будет логичным следующим шагом для репозиториев. Вот та бессвязная статья, которая использует CMS и синдикацию контента в качестве оправдания. Обратитесь к пункту разрешений ниже тоже.
Это мы забыли или недостаточно подчеркнули в 2010 году.
Права доступа.
Perforce, TFS и Subversion имеют возможность поддерживать отдельный доступ для чтения и записи для отдельных веток или каталогов внутри ветвей. Git и Mercurial нет. Если у вас есть, скажем, пароли базы данных в производственной или выпускной ветке, и вы не хотите, чтобы разработчики видели их, то Perforce, Subversion и TFS станут более надежными инструментами, поскольку вы можете ограничить доступ для чтения к этой ветке. Вы также можете не захотеть, чтобы разработчики могли изменять код в ветке, которая сопоставлена с производственной или является промежуточной версией, но все же разрешать им иметь доступ для чтения к источнику. Отладка может быть причиной этого. Эти инструменты также позволяют вам ограничить доступ к подкаталогам. Это очень мощно , и, возможно, я расскажу об этом в следующей статье.
В Github есть Forks (которые имеют отдельные разрешения), но это не то же самое, что возможность быть детально проработанным до уровня branch / directory / resource.
Распределенная природа
Mercurial и Git (два на уровне 5, как у нас было), это те, которые квалифицируются как DVCS среди тех, что мы перечислили. В то время как корпоративный пользователь управления исходным кодом, создающий одну разворачиваемую вещь (скажем, сайт для покупок), будет рассматривать одно хранилище (и одну ветвь внутри него) как каноническое место, работа классифицируется как «определенно выполненная» с точки зрения разработки на по крайней мере, есть другие источники контроля, которые не нуждаются в каноническом репо сервера. Поддерживаемое расхождение кода с точки зрения более чем одного «авторитета» является одним из примеров. Инструменты контроля версий, которые должны иметь master (например, Perforce, TFS и Subversion), намного слабее для этого сценария использования. «Местное отделение», которое предлагает Git / Mercurial, чрезвычайно расширяет возможности,но некоторые предприятия будут чувствовать себя лучше, если на каком-либо сервере с контролируемым доступом будет иметься единственное помазанное главное хранилище Subversion как окончательный центральный репо, сGit-SVN делать заказы популярны. Есть что-то похожее и с Git-Fusion от Perforce .
Переписывать историю
Некоторые инструменты «канонического сервера» гарантируют, что история не будет перезаписана через клиентский API. Некоторые из инструментов DVCS не имеют ограничений в этом отношении. Иногда упоминается Закон Сарбейнса-Оксли (SOX), часто такие юристы, как я. Существует гипотеза, что возможность переписывать (изменять или удалять) историю работает против соответствия SOX. У Mercurial есть режим работы, который предотвращает переписывание истории, поэтому мне сказали, но я не могу найти онлайн информацию для этого.
Исходно-контрольный инструмент «Круфт».
В случае с Subversion в каждой папке в SCM была папка .svn. Это было удобно, поскольку это позволило вам быстро скопировать эту папку (и сохранить связь с источником контроля) в другое место. Это было грубо, хотя. Разработчики ASP.Net привыкли иметь папки _svn вместо папок .svn, чтобы их инструменты были совместимы с Subversion. В последних выпусках Subversion с этим покончено. На самом деле, есть только одна папка .svn, и она находится в корневом каталоге.
Также в случае подрывной деятельности (исторически) существовали «списки свойств», которые были связаны с исходным файлом. Это полезно для метаданных, но предыдущий выбор заключался в использовании его для отслеживания точек слияния. При использовании для сложных конструкций веток это был невероятный беспорядок.
Частичная проверка дерева.
Это очень сильно относится к разрешениям выше. Subversion, Perforce и TFS могут извлекать из подкаталога любую ветку. Обычно это означает ствол, тег или ветку:
$svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk
# works
$svn checkout http://svn.apache.org/repos/asf/spamassassin/branches/3.0
# works
На этом все не заканчивается, вы можете перейти в подкаталог и проверить этот каталог и все более низкие или даже один ресурс (Perforce, TFS). Для Subversion отдельные файлы не допускаются, так как некуда было бы поместить папку .svn.
$svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk/build/
# works
$svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk/META.yml
svn: E200007: URL 'http://svn.apache.org/repos/asf/spamassassin/trunk/META.yml' refers to a file, not a directory
# fails for Subversion
Во-вторых, для переменных степеней можно настроить клиентскую спецификацию, чтобы создать маску того, что требуется при оформлении заказа. Perforce имеет клиентские спецификации, которые допускают такую конфигурацию (включая локальное переименование каталогов), TFS имеет рабочие пространства и сопоставления и маскировку рабочих папок . Subversion может опустить извлечение подкаталогов с помощью разреженного извлечения, которое также является мощным, но немного другим. Это оставляет вам возможность проверить их позже. Вам не понадобится ничего больше, чем простейшая конфигурация по умолчанию в 99% случаев, но иногда вы будете рады, что у вас был выбор для чего-то более сложного.
Конечно, за три года многое изменилось.
Пластмассовый СКМ появляется на сцене как сила. Он должен быть довольно конкурентоспособным, но у меня не было возможности попробовать это. Это даже не единственный новичок на блоке. Давайте даже не будем говорить об альтернативной науке об управлении источниками вокруг таких, как Даркс .
Team Foundation Server (TFS) от Microsoft становится намного лучше. Microsoft использовала «Source Depot» («sd» в командной строке) внутренне с конца девяностых годов . Для них это была дискретная перекомпиляция Perforce (‘p4’ в командной строке). TFS — это собственная попытка Microsoft реализовать ту же идею. Я не уверен, если это полностью то же самое, хотя. Внутренне они перевернулись из Source Depot где-то между 2008 и 2009 годами. Даже сегодня в пользовательском интерфейсе меньше пунктов меню, чем в Perforce. У Perforce (компании) есть сравнение на 12 страницах в формате PDF, которое вы можете прочитать, если хотите . Perforce (инструмент) — это прежде всего инструмент командной строки. Инструменты пользовательского интерфейса для Perforce (P4V и P4MERGE) кажутся вторичными. Для TFS Visual Studio ощущается как основной интерфейс и командная строкачувствует себя вторичным. Нет никаких сомнений в том, что TFS будет продолжать настаивать. Вполне возможно, что интеллигенция никогда не будет довольна количеством операций ввода-вывода между клиентом и сервером, которые могут произойти во время «открытия для редактирования» (переключения битов только для чтения), которые выслеживают TFS и Perforce.
Subversion тоже движется вперед. Лучшее разветвление и отслеживание точек слияния. Папки .svn, которые были распылены повсюду, пропали. Ошибка , которая стоила команде я был на сотни часов потерянного времени было зафиксировано.