version control - ClearCase vs SVN
поработав с годик под subversion, проникнувшись чуток идеологией и вообще попрактиковавшись, приходится признать, что хотя ClearCase и безмерно крут, но его модель поддержки версий и рабочих копий пользователя несколько хромает. Идеологически. Более того, пожалуй, и прививает некоторые неправильные идеи пользователям. Т.е. я по прежднему считаю, что поддержка branches в svn ужасна (т.е. создание branches посредством "копирования"), а в ClearCase великолепна (там branch отдельная сущность, и использование неограниченного количества branches для работы поощряется), я не очень озабочен монструозностью ClearCase, однако же, помимо этого, обычно критикуемого, есть ряд других весьма базовых аспектов, которые стали мне понятны лишь сейчас.

У меня сейчас под рукой нет ClearCase, чтобы экспериментально всё проверить, а голова уже сильно от него отвыкла, работу с ним я изрядно подзабыл (видимо, хороший Svn вытеснил воспоминания от CC) остается только воспользоваться документацией и заранее извиниться если что-то напутаю.

Итак, цитата из документации ClearCase:

update - Updates elements in a snapshot view
update does not apply to files or directories that are checked out to the current view

С другой стороны, припоминается, что в случае конфликта при check-in, когда после multiple-check-out второй пользователь должен мерджить свои изменения с изменениями первого, система не требовала проапдейтить остальные файлы в рабочем пространстве, которые первый пользователь при своём checkin мог изменить.

В совокупности (да даже и по отдельности!) это приводит к тому, что при одновременой работе нескольких пользователей на одной ветке, имея некоторую файлы в check-out нельзя быть уверенным, что после выполнения команды update в рабочем пространстве пользователя окажется ВЕСЬ зачекиненный другими людьми код (ибо его файлы, которые были в check-out не поменяются и не получат последних изменений).

С другой стороны, и в момент check-in в случае возникновения конфликтов нет никакой гарантии, что после разрешения этих конфликтов и checkin-a, на диске пользователя останется какая-то консистентная совокупность файлов, относящаяся к опреденной версии репозитория (+опциональная дельта, зачекиненная пользователем).

Всё это касается basic clear case, если мы рассмотрим UCM mode, там рекомендуется каждому работать на своей ветке (это не всегда возможно и совсем не всегда оправданно), и, вроде бы, соответствующие команды вроде "rebase", могут работать и когда файлы пользователя находятся в checkout, но... документация рекомендует как раз все файлы перед rebase всё-таки зачекинить. :-)

Но, допустим, даже если "rebase" (аналог "update"-a для работе на индивидуальных branches) работает корректно и удобно (три раза ха!), остается еще "deliery" (аналог chekin-a), который опять же предложит разрешать конфликты на частных файлах, а не предварительно заребейзиться по всем файлам на самую последнюю версию. Впрочем, последнее, видимо, можно всё же как-то настроить. Во всяком случае, документация говорит об опционально настройке policy, требующей предварительный rebase на "рекомендуемую" конфигурацию версий aka "baseline", что при этом рекомендовано делать пользователю если такого рекомендованного baseline нет, либо же нет никакого последнего baseline, остается за кадром. Видимо, всё же предполагается пофайловый мердж с риском появления, опять же, неконстистентного набора версий в рабочем пространстве мерджа.

Кстати, работа в UCM моде приводит дерево версий к совершенно невменяемому состоянию, поскольку каждый rebase файла, который уже пользователем был на ветке изменён, приводит к реальному merge в дереве версий. То прекрасное дерево версий, за которое я ценил ClearCase превращается в сплошной и бессмысленный кошмар.

Вообще, видимо, та или иная стратегия поддержки консистентности пространства пользователя - это набор компромиссов и невозможно однозначно судить, что более полезно и что менее опасно. Скажем, та поддержка констистентности, которая обеспецивается в SVN, достигается, мне кажется, повышением риска потери изменений из-за ошибок в merge. Не то чтоб в ClearCase можно было бы мерждить что-то принципиально проще в тех или иных случаях, но по крайней мере в ClearCase этот merge происходит перед check-in, а в SVN в том числе и при update пространства пользователя, что, мне кажется, расслабляет и провоцирует некоторую неряшливость. Возможно, для работы низкоинтеллектуальных пользователей модель Clear-Case в этом плане менее опасна, но, как по мне, при некоторой аккуратности, в SVN всё-таки работать веселее и в конечном итоге проще и надёжнее.
--------------------
вообще, конечно, экспертная оценка этих вещей довольно непроста. особо когда экспертом и не являешься. а работая на той или иной системе, становишься жертвой своеобразного стокгольмского синдрома, когда начинаешь мыслить в терминах дизайна, а то и частностей имплементации системы, на которой работаешь, и не понимаешь, что мыслишь не самостоятельно, а по навязанному стереотипу.