Предполагая, что вы ограничены двумя системами управления версиями (VCS), которые вы упомянули, Subversion (SVN) будет понятнее, проще и лучше поддерживаться практически во всех отношениях, пока вы не достигнете точки, в которой вы должны поддерживать несколько ветвей.
Когда вам нужно объединить код (например, исправления ошибок) в несколько версий, поддерживать параллельную разработку любых объектов значительно большего размера или немного более многочисленную команду разработчиков, чем ClearCase, и, в частности, возможность разрабатывать в ветвях и объединять их вместе легко, станет стоить всей дополнительной боли и осложнений, особенно если ClearCase уже управляется для вас.
Опыт
Я использовал ClearCase с одним человеком (мной) и более чем с 400 людьми. У него много повседневных неудобств, проблем с юзабилити и сбоев, но он постоянно позволяет нам работать вместе. При установке ClearCase всегда были выделены администраторы, занятые полный рабочий день.
Я использовал Subversion сам и с одним другим человеком, и он отлично работает изо дня в день (без администраторов, кроме меня), но очень редко, но постоянно становится значительным источником разочарования из-за того, что он не может обрабатывать какие-либо существенные ситуации ветвления и слияния.
Почему SVN плохо поддерживает параллельную разработку и ветвление?
SVN не поддерживает параллельные линии разработки, поскольку имеет очень слабую автоматическую поддержку объединения ветвей. В отличие от всех других VCS, о которых я пишу здесь, есть хорошая поддержка для объединения ветвей; для общих случаев это операция с нулевым усилием.
Ветвление - это способ, которым системы контроля версий моделируют параллелизм в жизни человека (например, два разработчика работают над двумя разными проблемами параллельно или один разработчик, у которого одновременно открыто несколько проблем). Но ветвление бесполезно, если вы не можете легко объединить работу каждого в единое целое!
Ветвление может происходить явно (в том смысле, что они называются и понимаются VCS) или неявно (как обычная копия файлов или извлечение). SVN поддерживает и то и другое, но в SVN ветвление обычно выполняется неявным ограниченным образом. Каждый извлечение является ветвью, но все ветки вынуждены синхронизироваться при каждой фиксации / обновлении. Это происходит потому, что SVN не поддерживает простое объединение явных ветвей и, следовательно, явные ветки создаются редко.
Поскольку вы вынуждены синхронизироваться друг с другом при каждом коммите, это уменьшает потенциальный параллелизм внутри команды. Это также приводит к не совсем идеальным методам разработки, поскольку вы не можете эффективно использовать систему контроля версий для собственных повседневных нужд разработки. В итоге становится слишком сложно опробовать разные идеи в своих личных ветках, и вы не можете сделать несколько коммитов при усовершенствовании функции. У вас также больше шансов совершить коммит слишком рано и в конечном итоге нарушить работу других, пока не решите проблему в своем последнем коммите.
Другая важная проблема заключается в том, что, поскольку объединение явных веток не поддерживается должным образом, SVN плохо помогает перемещать изменения кода между людьми и между ветвями. Представьте, что вы пытаетесь исправить ошибку как в ветке релиза, так и в ветке разработки; в качестве альтернативы представьте, что два разработчика работают над связанной функцией, и им обоим необходимо вносить изменения друг в друга, но только в контролируемых точках. Используя SVN, вы можете выполнять эти задачи, но VCS делает очень мало, чтобы помочь вам, и вы должны быть готовы вручную подготовить и поддерживать исправления или отправлять файлы.
В других VCS вы можете попросить VCS объединить ветку, содержащую исправление ошибки или функцию, в различные другие ветви.В конце дня все эти ветви (которые сами содержат содержимое других ветвей) могут быть затем объединены в основную ветку.Чаще всего это будет автоматически и правильно обрабатываться VCS, тогда как SVN с такой гибкостью и параллелизмом практически невозможен.
Большие команды выполняют работу без сильной поддержки автоматического объединения.но это накладывает большее бремя как на отдельных лиц, так и на организацию команды, коммуникацию и процесс.
С другой стороны, недостатком простоты ветвления и слияния является то, что вы должны быть организованы и неукоснительно относиться к объединению изменений врегулярные интервалы, поскольку это больше не происходит автоматически.
Другие параметры
Теперь, если мы сделаем шаг назад и рассмотрим другие системы, предполагая, что ваш репозиторий в основном текстовыйНа основании относительно небольшого размера (менее нескольких сотен МБ) я бы посоветовал вам серьезно рассмотреть возможность использования BZR .BZR, по крайней мере, так же прост в использовании, как SVN, особенно если вы уже знаете SVN.Он также по крайней мере такой же мощный, как ClearCase во всех важных отношениях с точки зрения разработчика;он поддерживает несколько потоков (ветвей) разработки и имеет хорошую поддержку для их объединения.В то же время он может поддерживать централизованный стиль разработки по мере необходимости.
Хотя у меня нет опыта работы с ним, я должен также упомянуть, что вы можете использовать инструмент BZR для доступа к серверу SVN с bzr-svn , и это может дать вам много преимуществ и возможностей слияния BZR, сохраняя при этом преимущество размещения вашего кода на широко понимаемой платформе SVN.
Хотя я только что предложил BZR, в мирес открытым исходным кодом распределенные системы контроля версий (DVCS), многие люди, кажется, собираются с GIT .Я не предлагал этого, так как это заставляет пользователей учиться на SVN более крутой кривой обучения, и я думаю, что многие команды в дикой природе предпочли бы лучшую поддержку Windows и простоту использования BZR, а не преимущества GIT в отношении масштабируемости и скорости..
Если вы решите использовать DVCS, например BZR или GIT, вам, вероятно, не нужно слишком зацикливаться на том, какой именно DVCS вы начнете использовать.Все широко используемые системы поддерживают экспорт и импорт между собой и могут по крайней мере импортировать из SVN.