Преимущества/недостатки ClearCase [закрываются]
Если вы хотите, чтобы ваше намерение обрабатывалось только приложением электронной почты (а не другими приложениями для обмена текстовыми сообщениями или социальными приложениями), то используйте действие ACTION_SENDTO и включите схему данных «mailto:». Например:
public void composeEmail(String[] addresses, String subject) {
Intent intent = new Intent(Intent.ACTION_SENDTO);
intent.setData(Uri.parse("mailto:")); // only email apps should handle this
intent.putExtra(Intent.EXTRA_EMAIL, addresses);
intent.putExtra(Intent.EXTRA_SUBJECT, subject);
if (intent.resolveActivity(getPackageManager()) != null) {
startActivity(intent);
}
}
Я нашел это в https://developer.android.com/guide/components/intents-common.html#Email
28 ответов
You can find a good comparison between ClearCase and Git in my SO answer:
"What are the basic ClearCase concepts every developer should know?", illustrating some major differences (and some shortcomings of ClearCase)
File-centric operations
The most single important shortcoming of ClearCase is its old "file-centric" approach (as opposed to "repository-centric" like in SVN or Git or Perforce...)
That means each checkout or check-in is done file per file. The atomicity of operation is at file levels.
Combine that with a very verbose protocol and a network with potentially several nodes between the developer workstation and the VOB server, and you can end up with a fairly slow and inefficient file server (which ClearCase is at its core).
File-per-file operations means: slow recursive operations (like recursive checkout or recursive "add to source control", even by clearfsimport).
A fast LAN is mandatory to mitigate the side-effects of that chatty protocol.
Centralized VCS
The other aspect to take into account is its centralized aspect (even though it can be "distributed" with its multi-site replicated VOB feature)
Если сеть не разрешает доступ к VOB, разработчики могут:
- по-прежнему работать в представлениях моментальных снимков (но только с захваченными файлами)
- ждать восстановления сети, если они используют динамические представления
Дорогой Опция распределенной VCS
Вы можете получить некоторую функцию распределенной VCS, реплицируя Vob.
But:
- you need a special kind of license to access it.
- that license is expensive and add to the cost of the regular license
- any vob that uses the replicated vob (admin vob, admin pvob, ...) must be replicated as well (meaning some projects not directly concerned with a distributed development will still have to pay multi-site license...)
Old and not user-friendly GUI
- the GUI is very old school and impractical (mid-90's MFC look, completely synchronous GUI, meaning you have to wait for a refresh before clicking elsewhere): when browsing baselines, you cannot quickly look for one in particular.
- the GUI on Unix is not exactly the same than on Windows (the latest 7.1 version is better but not there yet)
- the installation process is quite complicated (although the latest Installer Manager introduced by CC7.1 is now a coherent GUI on Windows or Unix and does simplify the procedure)
- the only real rich application has only been developed for CCRC (the Remote Client)
UCM inconsistencies and in coherencies
As mentioned in "How to Leverage ClearCase’s features", dynamic views are great (a way to see data through the network without having to copy them to the disk), but the main feature remain UCM: it can be a real asset if you have big project with complex workflow.
Some shortcomings on that front:
- the dependencies between components is not well managed for a depth superior to one (because of the bug of "parasite baseline")
- UCM still has some in coherencies and inconsistencies as documented in CM Crossroads
Limited policies with Base ClearCase
Using ClearCase without using UCM means having to define a policy to:
- create branch (otherwise anyone can create any branch, and you end up with a gazillon of them, with merge workflow nightmare)
- put labels (otherwise you forget to label some files, or you put a label where you were not supposed to, or you "move" (gasp) a label from one version to another: at least UCM baselines cannot be moved)
- define changeset. ChangeSets only exist with UCM activities. With Base ClearCase, you are reduced to clever "
cleartool find" requests...
No application rights
ClearCase right management is entirely built on system rights.
Это означает, что вам необходимо зарегистрировать своего пользователя в правильной системной группе, что не всегда легко сделать, когда вам нужно ввести билет в свою ИТ-службу, чтобы они могли правильно зарегистрироваться.
Add to that an heterogeneous environment (users on Windows, and server on Unix), and you need to register your user on Unix as well as Windows! (with the same login/group name). Unless you put some sort of LDAP correspondence between the two world (like Centrify)
No advanced API
- only CLI is complete ("
cleartool" is the ClearCase Command Line Interface), meaning that any script (in Perl or other language) consists in parsing the output of thosecleartoolcommands) - ClearCase Automation Library (CAL) exists, but is quite limited
- Java API exists, but only for web views for the CCRC client.
View Storages not easily centralized/backed up
The View storages are the equivalent of the ".svn" of SubVersion, exept there is only one "view storage" per view instead of many .svn in all the directories of a SubVersion workspace. That is good.
What is bad is that each operations within a view (a simple "ls", checkout, checking, ...) will trigger a network request to the view_server process that manages your view server.
2 options:
- declare your view storage on your workstation: great for scalability, you can have as many view as you want without taxing the LAN: all communications are directly done on your workstation. BUT if that machine dies on you, you loose your views.
- declare your view storage on a centralized server: that means all view_server process will be created there and that all operations on a view by any user will have to communicate with that server. It can be done if the infrastructure is "right" (special high-speed LAN, dedicated server, constant monitoring), but in practice, your LAN will not support this mode.
The first mode means: you have to backup yourself your work in progress (private files or checked-out files)
The second mode means: your workstation can be unavailable, you can just log on another a get back your views (execpt for the private files of a snapshot view)
Side discussion about dynamic views:
To add to the "dynamic view" aspect, it has one advantage (it's dynamic) and one shortcoming (it's dynamic).
Dynamic views are great for setting a simple environment to quickly share a small development between a small team: for a small development effort, a dynamic view can help 2 or 3 developers to constantly stay in touch one with another, seeing instantly when one's commit breaks something in the other views.
Для более сложных разработок предпочтительна искусственная «изоляция», обеспечиваемая просмотром снимка (вы видите изменения только тогда, когда обновляете - или «обновляете» - свое представление снимка)
For real divergent development effort or course, a branch is still required to achieve true code isolation (merges will be required at some point, which ClearCase handles very well, albeit slowly, file-by-file)
The point is, you can use both, for the right reasons.
Note: by small team I do not mean "small project". ClearCase is best used for large project, but if you want to use dynamic views, you need to setup up "task branches in order to isolate a small development effort per branch: that way a "small team" (a subset of your large team) can work efficiently, sharing quickly its work between its members.
If you use dynamic views on a "main" branch where everyone is doing anything, then any check-in would "kill you" as it could introduced some "build breaks" unrelated with your current development effort.
Тогда это было бы плохим использованием динамических представлений, и при этом были бы забыты другие его применения:
- дополнительный способ доступа к данным , в дополнение к представлениям моментальных снимков, что означает, что это отличный инструмент, чтобы просто «увидеть» файлы (вы можете, например, использовать динамическое представление, чтобы настроить его конфигурационную спецификацию, пока не увидите то, что вы хотите, а затем скопируйте эти правила выбора в ваше обычное представление моментального снимка)
- вид сбоку для выполнения слияний : вы работаете со своим представлением моментального снимка, но для слияний вы можете использовать свой динамический «сестринский вид» («сестра», как в «той же спецификации конфигурации»), чтобы избежать неудачного слияния из-за извлеченных файлов (на который вы в настоящее время будете работать над своим представлением снимка), или из-за того, что представление снимка не полностью обновлено. Как только слияние будет завершено,
Это означает, что DLL, jar или exe, необходимые для вашей IDE, будут доступны по сети, что может значительно замедлить процесс компиляции.
Возможные решения:- одно представление снимка со всем в нем
- представление снимка с dll, jar или exe в нем (файлы, которые не меняются каждые пять минут: одно обновление в день) и динамическое представление только с исходными кодами visible.
Я бы предложил SVN для набора инструментов и Git для масштабирования / рабочего процесса. Я также предлагаю по возможности избегать CC. (Не считая денег, тот факт, что пользоваться им так неудобно, что требуется постоянный администратор, - полная шутка)
Производительность.
ClearCase мощный, стабильный (если правильно обслуживается и контролируется), но он медленный. Иногда геологические.
Виды динамических представлений приводят к ужасным временам построения, представления снимков могут занять много времени для обновления (перерыв на обед для больших проектов) или оформления заказа (уходите домой на день).
Мой опыт работы с ClearCase был катастрофой, и я поддержу заявление Дона о том, что для этого требуется постоянный эксперт - к сожалению, у нас их было несколько. У меня был опыт работы с CVS и другими системами контроля версий, я был знаком с концепциями, но нашел документацию ClearCase непонятной, и мне пришлось несколько раз просить о помощи; разные эксперты дали мне противоречивые советы до такой степени, что мы фактически сломали cd . То есть, после того как я ввел команду ClearCase в оболочке UNIX, команда "cd" завершилась ошибкой
. Основная задача системы контроля версий действительно довольно проста. Честно говоря, я думаю, что полдюжины команд должно хватить, используя файловую схему, которая хорошо сочетается с другими. Для меня ClearCase выглядит как результат того, что руководитель отдела маркетинга намеренно усложняет все, чтобы продукт выглядел сложным и мощным. Я слышал, что его можно настроить так, чтобы он работал простым, безопасным и надежным способом, но опять же, для этого требуются услуги эксперта - прямо из коробки это похоже на моторизованный швейцарский армейский нож.
Стоимость является довольно очевидным недостатком. Не только стоимость лицензии, но и стоимость зарплаты гуру ClearCase. Почти в каждой известной мне компании, использующей ClearCase, кажется, есть по крайней мере один человек, единственная цель которого - приручить непокорного зверя.
Сам факт того, что это достаточно сложно, чтобы требовать постоянной няни, также беспокоит.
Everything I have done in Clearcase always seems hard. Whereas, I've never had that impression with other systems(except maybe CVS on occasion).
I've used SVN, CVS, Clearcase, and Mercurial.
Самым большим недостатком для меня является как производительность (особенно, если ваш VOB - это мультисайтовый или внешний), так и потенциально длительные простои.
Если вы похожи на меня и работаете в относительно небольшом в офисе в составе крупной компании (без ИТ-отдела), выход из строя серверов Clearcase может стоить вам большей части рабочего дня из-за непроизводительной работы, а также привлечения нужных людей для ремонта.
Итог, используйте это только в том случае, если он вам действительно нужен для того, что вы делаете, и убедитесь, что у вас есть солидный ИТ-бюджет для его обслуживания.
Я не категорически против ClearCase (он есть ' s преимущества), но перечислим недостатки:
- Ограничения лицензии - мне нелегко работать из дома, потому что у меня нет доступа к серверу лицензий. Даже с просмотром снимка на моем ноутбуке я должен подшучивать, потому что я не могу получить лицензию. Существует специальный удаленный клиент, но он добавляет к нему массу собственных ограничений.
- Опять ограничения лицензий - достаточно много рабочих мест, и никто не может его использовать.
- Инструменты Unix устарели - ClearCase кажется, лучше всего работает в системах Unix, но инструменты с графическим интерфейсом там никуда не годятся. Интеграция ClearCase в Windows / Unix привносит множество проблем.
ClearCase снаружи кажется чрезвычайно мощным. Но на самом деле, просто количество команд и параметров, которые вам нужно использовать для основного рабочего процесса, настолько велико, что они скрываются за несколькими псевдонимами или скриптами, и вы получаете что-то менее мощное, чем CVS, с удобством использования Visual Source. Безопасно. И каждый раз, когда вы хотите сделать что-то более сложное, чем позволяют ваши сценарии, у вас возникает болезненное ощущение в животе.
Сравните это с Git, который со стороны кажется сложным, но после недели работы с ним вы чувствуете полностью под контролем. Модель репозитория проста для понимания и невероятно эффективна. Поскольку до гайки и болта легко добраться, на самом деле приятно копать под поверхностью повседневного рабочего процесса.
Например, На выяснение тривиальной задачи, например, как просто просмотреть не-HEAD версию файла в режиме моментального снимка, у меня ушло несколько часов, и в итоге я получил полный взлом . Не самый приятный вид взлома.
Но в Git выяснение, казалось бы, сложной задачи, например, как интерактивно зафиксировать только некоторые изменения (а остальное оставить на потом) было большим развлечением, и все время у меня ощущение, что VCS позволяет мне организовать код и историю таким образом, который мне подходит, а не история как случайность того, как мы использовали VCS. «Git означает, что никогда не нужно говорить« вам следует иметь »» .
В своей работе я использую Git для всех видов легких задач, даже в ClearCase. Например, я использую TDD и передаю Git всякий раз, когда проходит несколько тестов и я собираюсь провести рефакторинг. Когда задача в конечном итоге выполнена, я проверяю ClearCase, и Git помогает мне точно проверить, что я меняю. Просто попробуйте заставить ClearCase произвести различие между парой файлов - он не может! Используйте Google, чтобы узнать о различных хитростях, которые люди пытались обойти. Это то, что система управления версиями должна делать из коробки, и это должно быть легко! CVS использует это десятилетиями!
Atomic commits and changesets are my biggest gripes against ClearCase. Let's say you check in five files as part of a bug fix or refactoring. Then it is discovered that something got messed up and you need to revert. Good luck finding which five files they are and what version each one needs to be on. But let's take a step back. You have just finished editing those five files, and it's time to commit. The first four go through just fine. That last one requires a massive merge. The other four files are already checked in. They don't wait for you to finish your necessary changes in the last file. I sure hope that no one updated or is using a dynamic view. A continuous integration build server is going to fail too.
Sometimes we make a whole new directory full of files that need to be checked in, but we don't want to check them in until they are done. It's early and everything is still volatile, so why check things in that you might delete very soon? OK, fine so far. Now it's time to check in. You add the newly created folder to source control. Well, ClearCase isn't recursive, so only that single folder is checked in. With SVN, that folder and everything below it is added, as you choose. The developer needs to remember to add everything, otherwise, a lot of files are going to be missing.
ClearCase owns the files and folders so you cannot modify anything unless you have checked it out first. The eclipse plugin takes away a lot of the nuisance here. I can't tell you how many times I opened a file in vi to make a quick change, only to find that I had forgotten to check it out first. Checkout isn't recursive either.
Updates can be painfully slow without changesets. When you update with a snapshot view, every file updates, not just the modified files. I worked on a project with 20,000+ files. I would remote in to my work machine, start the update, then drive to work; get coffee; go to my desk while it was finishing up. That might sound like an exaggeration, but it sadly isn't.
Dynamic views are terrible unless you are in a very small team. And if that's the case, why do you even have ClearCase? I have seen countless people's views getting hosed because someone checked in files that broke the views of everyone else. You should always update and merge any conflicts on your own view. That way, the changes only affect you. With a dynamic view, you cannot merge down before pushing back up; you just commit and hope.
I know cost probably isn't a big concern, but the developers who make the money for the company would enjoy spending the $50k-$100k (depending on ClearQuest license, which is a common addition) on either fun events or new equipment (chairs, monitors, etc.). IBM recommends having staff to keep ClearCase going. Why not re-purpose those people to generate revenue for the company, instead of making sure things don't crash and burn?
Some of the reasons that I have heard for not switching:
- Learning will take time and money
- Изучение SVN или Mercurial не должно занимать больше дня. Только ClearCase предлагает определенное соотношение администраторов и разработчиков.
- Миграция будет болезненной.
- Вот почему существуют инструменты: cc2svn
- Это не так просто с Mercurial
- Security
- В SVN AFAIK нет известных зияющих дыр, и команда разработчиков стремится исправить все, что обнаруживается быстро. Министерство обороны, похоже, устраивает SVN.
- Никакого реального повышения производительности после этого не произошло.
- На поиск ошибок без наборов изменений уходит много времени. Я люблю откатиться назад, пока не перестану видеть ошибку. Вы не можете этого сделать в ClearCase.
- Multisite
- WANdisco решает эту проблему. Однако это не бесплатно.
Единственное, что ClearCase делает лучше остальных, - это разветвляет отдельные файлы, сохраняя при этом остальные на том же пути, что и другая ветвь.
Возможно, я буду здесь один, но ClearCase не так уж и плох, как все говорят. Он может обрабатывать огромных хранилищ. Динамический просмотр - тоже довольно крутая и мощная функция. Он надежен, его можно настраивать путем добавления триггеров и ограничений на основе файла pef, разрешений и т. Д.
К сожалению, он имеет свою цену, большую цену. Это дорого и требует правильной настройки и обслуживания специальной ИТ-командой. Это действительно хорошо для BigCo, но не очень разумный выбор для SmallFirm.
Я большой поклонник DVCS и git, но могу понять, почему BigCo предпочел ClearCase SVN и Git. Чего я не могу понять, почему кто-то предпочел SVN Git;>
Запуск JDK из VOB в Linux.
Попробуйте, вам нужно поиграть с переменной LD_PRELOAD (я знаю!)
ClearCase отлично подходит для использования, если вы хотите использовать еще одну систему контроля версий поверх нее! Лично я считаю, что использование Mercurial поверх CC работает достаточно хорошо.
Недавно мне пришлось столкнуться с подобной ситуацией. Может быть, вы сможете извлечь уроки из моей истории.
Команда, в которую меня недавно назначили, использовала тяжелый инструмент запутанным, подверженным ошибкам способом. Сначала я попытался продать им свои инструменты и процессы. Эта попытка с треском провалилась. Я был ошеломлен тем, что они предпочли такую обременительную среду более простой и эффективной. Оказывается, они хотели быть дисциплинированными и, используя болезненный процесс, чувствовали себя дисциплинированными. Звучит странно, но это правда. У них тоже было много других заблуждений. После того, как я понял, что им нужно, мы фактически остановились на том же наборе инструментов (Серена), но сильно изменили его настройку.
Мой вам совет - выяснить, что важно для вашей команды. Копирование ClearCase ни к чему не приведет, если вы не поговорите с их интересами. Также выясните, почему они не хотят использовать альтернативы. По сути, сделайте небольшой сбор требований и приспособьте свой выбор инструментов к вашим потребностям.
Clearcase настолько раздражает, что на самом деле заставляет людей писать стихи о нем:
http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control .html
http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/
- Кошмар для администрирования в безопасной среде
- Устаревшая технология
- Неинтуитивный графический интерфейс
- Дорогой
- Монстр ресурсов
- Продажа Microsoft
На мой взгляд? Единственная причина иметь это? Если вы неукоснительно следуете RUP.
Недостатки ClearCase - добавление к самому подробному посту здесь.
Инструмент слияния бесполезен. Он почти не помогает вам, не запоминает никаких решений, которые вы принимали, это просто прославленная разница.
Инструмент слияния должен проверять каталоги, чтобы даже ПРОВЕРИТЬ, если они нуждаются в слиянии. Это немного безумие.
Я использую BitKeeper на работе (предположим, Git), и объединение двух репозиториев, даже если есть конфликты, настолько тривиально и удобно для пользователя даже с помощью командной строки, в то время как ClearCase, имеющий множество инструментов с графическим интерфейсом, - длинный и трудоемкий процесс, который также чрезвычайно подвержен ошибкам.
Все инструменты с графическим интерфейсом требуют огромной задержки. Даже просмотр того, что можно сделать с файлом, требует высокоскоростного соединения. Таким образом, щелчок правой кнопкой мыши в инструменте ClearCase по файлу, работающему из дома, может занять минуту или две при наличии высокоскоростного Интернета из-за чрезмерного количества сетевых требований.
Кто-то может полностью испортить репозиторий или проверки, если они сделают их точка зрения отличается от спецификаций команды. Что совершенно безумно, что никто не может просто проверить какую-то ветку; им нужна соответствующая спецификация просмотра, которая, кстати, даст им нужные вещи. Вся концепция может быть красивой и гибкой, но в 99% случаев она вызывает много боли. Я упоминал, что вы не можете отправить свою спецификацию по электронной почте через Microsoft Outlook, поскольку инструменты CC не принимают UTF-8, поэтому вы не можете скопировать и вставить его?
У меня нет абсолютно ничего , о чем можно сказать хорошего CC. Я использовал его в течение 2 лет в 2 компаниях и бросил его в мгновение ока, чувствуя себя все время счастливым. Также невозможно просто поэкспериментировать дома со своими собственными проектами, поэтому вы все равно будете изучать SVN или Git дома и будете вынуждены проходить через боли ClearCase на работе. Никто из моих знакомых никогда не использовал CC добровольно. Они используют его только потому, что какой-то менеджер на работе решил, что CC - это путь к спасению, и заставил всех перейти на него. Фактически моя последняя компания перешла с CVS на ClearCase, а через год с ClearCase на SVN. Это было то, что ненавидели.
ClearCase - это не просто одна вещь, которая заставляет вас сказать «нет». Это как жить в доме, кишащем муравьями. Каждый муравей доставляет в лучшем случае лишь незначительное неудобство, но заражение сведет вас с ума.
Поддержка ужасная. Билеты открыты уже много лет. Наш гуру eclipse фактически исправил ошибку в своем плагине eclipse локально примерно за 30 минут, дизассемблировав файл java. Но билет все еще не получил поддержки первого уровня. Время от времени они либо пытаются украдкой закрыть его, либо отправляют нам эхо-запрос «попробовать последнюю версию» (хотя мы отправили им рецепт воспроизведения, который они могли бы попробовать сами).
Не прикасайтесь к нему шест для отталкивания баржи.
Я пытаюсь объединить несколько комментариев в настоящий пост здесь. Я здесь не для того, чтобы убеждать вас в том, что один лучше другого, за исключением того, что хочу отметить несколько моментов:
- Если вы сравниваете git и ClearCase, я с уважением заявляю, что вам нужно лучше определить свои потребности - если вы рассматриваете ClearCase по "уважительной" причине, git, вероятно, не Даже в уравнении - это слишком ново, чтобы доверять системе управления версиями на уровне предприятия, имо.
- ClearCase вводит множество концепций в пространство управления версиями, которых нет в других системах, так что это может быть довольно сложно и сбивает с толку. Особенно, если единственный опыт, который у вас есть, - это чтение документации, что, по-видимому, имеет место для некоторых здесь людей.
- ClearCase определенно не подходит для огромных баз кода, поддерживаемых разработчиками, которые не находятся в локальной сети с VOB-сервером. . Вы можете иметь много реплицированных (многосайтовых) серверов VOB, чтобы приблизить их к удаленным разработчикам, но это не обязательно практично, если эти удаленные сайты являются всего лишь одним разработчиком.
- Хотите ли вы управлять версиями файлов или репозиториями? Это довольно важный вопрос, и он обязательно отфильтрует весь набор инструментов, облегчая вашу работу. Управление версиями репозитория имеет множество преимуществ (и оно не «новое», как утверждали некоторые плакаты - коммерческие инструменты, такие как Perforce, существуют уже более десяти лет, и, возможно, были инструменты, которые выполняли управление версиями репозитория даже до Perforce), но это не панацея.
- При достаточно большой установке любой системы управления версиями вам понадобится помощь. При рассмотрении инструментов вы должны учитывать, насколько легко будет найти людей, которые могут вам помочь (либо соискателей, у которых есть опыт, либо консультантов, которые будут всегда готовы ответить на любые вопросы). Не существует такой вещи, как необслуживаемая система SCM, и, предположив, что она у вас есть, вы столкнетесь с большими проблемами, чем выбор системы, требующей "слишком большого" администрирования.
- Дон ' Не обращайте слишком много внимания на людей, которые говорят о том, насколько плохи «динамические представления» - плохие политики SCM плохи, независимо от того, какой инструмент вы используете. Ваши политики и методы управления конфигурацией должны быть отделены от вашего выбора инструмента - ни один инструмент не остановит людей от разрушения вашей кодовой базы, если вы не определите разумные политики ветвления и слияния. Если кто-то предполагает, что прямая фиксация разработчиков в / main - это разумная идея, вы можете отказаться от этого разговора.
ClearCase - прекрасный инструмент, но это сложный инструмент. Здесь не обойтись - у него нет режима «простой установки». :-) С технической точки зрения, нет ничего такого, что может сделать git или SVN, чего не может ClearCase (хотя часто терминология отличается, поскольку проекты с открытым исходным кодом имеют тенденцию просто изобретать новую таксономию там, где она уже существует), но некоторые вещи определенно проще / сложнее для данной системы, в зависимости от их дизайна. Представления «моментальных снимков» ClearCase - это в основном то же самое, что и при извлечении репозитория из SVN или CVS - это локальная копия исходного кода на вашем компьютере с указателями обратно на центральный сервер для инструментов для запроса истории версий, и т. д. Вы можете работать с этими представлениями без какого-либо сетевого подключения к серверу ClearCase сразу после их создания, и вы можете «переработать» их, чтобы избежать повторной загрузки всего репозитория, когда вы хотите перейти для работы в другой ветке, для пример. «Динамические просмотры» - это, по сути, изобретение ClearCase и стандартный рабочий режим для локальной сети. Они выглядят так же, как проверка репозитория SVN, но на самом деле они не копируют никаких файлов, пока вы не внесете изменения. Таким образом, представление становится доступным немедленно, но, очевидно, с ним нельзя работать, если основной сервер в открытом виде недоступен, и с ним неприятно работать через соединение с высокой задержкой. У них также есть удобство того, что они могут быть смонтированы как сетевой диск на любой машине с доступом к серверу, на котором они были созданы, поэтому, если ваша рабочая станция Windows умирает, вы можете просто войти на другую, смонтировать свое представление и получить вернуться к работе, поскольку все файлы хранятся либо на сервере VOB (для файлов, которые вы не изменяли в этой ветке), либо на view_server (для файлов, которые вы создали или изменили только в этом представлении).
Кроме того, и это заслуживает отдельного абзаца .... clearmerge почти стоит только цены входа. Это лучший инструмент слияния, который я когда-либо использовал в своей жизни. Я твердо уверен, что из-за отсутствия высококачественных инструментов слияния появилось много плохих практик в SCM, поэтому пользователи CVS так и не научились правильно использовать ветки, и этот страх перед ветвлением распространился до сегодняшнего дня без особо веских причин.
Хорошо, все, что было сказано, если вы ищете причины не использовать ClearCase, их нетрудно найти, хотя я думаю, что это неправильный путь. На самом деле вам нужно найти веские причины для использования ClearCase, а не причины НЕ использовать ClearCase. Вы должны входить в любую ситуацию SCM, предполагая, что ClearCase - это слишком много инструмента или слишком сложный инструмент для работы, а затем посмотрите, есть ли у вас ситуация, которая побуждает вас в любом случае использовать его. Наличие логотипов IBM или Rational не является уважительной причиной ..: -)
Я бы даже не стал рассматривать ClearCase, если бы вы не сказали «да» на все следующие утверждения:
- У вас есть сейчас или в конечном итоге будет более 50 разработчики, работающие над одной и той же кодовой базой.
- Большинство этих разработчиков расположены в центре или имеют высокопроизводительные соединения с низкой задержкой с центральным расположением.
- У вас есть набор политик SCM, и вы можете определить, как использовать ClearCase для обеспечить соблюдение этих политик (действительно, вы должны учитывать это для любого инструмента)
- Деньги на самом деле не объект
Нет атомарных коммитов
После того, как вы отметили файлы, очень сложно вернуться к определенному состоянию, потому что атомарные коммиты не поддерживаются. При регистрации нескольких файлов каждый файл получает новую ревизию (аналогично CVS), а не саму регистрацию. Я думаю, что это важная функция, потому что вам вряд ли нужно возвращать отдельные файлы, а выполнять действия фиксации (которые должны отображать задачи). С ClearCase вы можете вернуться к определенным состояниям только с помощью меток. На практике использование ClearCase Labels для каждой регистрации является излишним, и поэтому не делается.
Дрянный пользовательский интерфейс
Графический интерфейс ClearCase Explorer - это просто большая шутка. Ужасно с точки зрения удобства использования и некрасиво выглядит. Не предусмотрены различные и часто необходимые функции (например, рекурсивная проверка проработанных артефактов). Инструмент командной строки cleartool, используемый с cygwin, намного лучше, но все же некоторые вещи недоступны, например, рекурсивное добавление новых файлов / папок в систему управления версиями. Мне придется смеяться над головой, если я прочитаю сценарий длиной 50 строк, чтобы обойти эту проблему.
Высокие усилия по администрированию
Администрирование ClearCase - далеко не очевидное или легкое занятие (в отличие от других scm-систем, таких как CVS, subversion или Git). Ожидайте, что придется нанять немало преданных экспертов ClearCase, чтобы просто поддерживать его работу.
Ужасная производительность
Нет ничего хуже, чем заставлять ваших разработчиков ждать, пока они взаимодействуют с SCM-инструментом, это похоже на вождение с включенным ручным тормозом. Это замедляет ваш мозг, а также вашу работу. Добавление новых файлов в представление моментального снимка занимает около 30 минут для 10K артефактов. Обновление (никакие артефакты не менялись) на такое же количество занимает примерно 5 минут. Когда много экспериментируешь и перепрыгиваешь между разными актуальными представлениями, приходится долго ждать. Еще хуже, когда вы работаете с файлами и хотите вернуть или обновить их. Выписка, регистрация и добавление в циклы управления версиями занимают около 10-15 секунд, что, очевидно, является кошмаром. Это очень раздражает, когда вы проводите рефакторинг, переименовывая / перемещая типы или методы (многие файлы могут быть затронуты).
Отсутствие поддержки распределенной разработки
Сегодня разработка программного обеспечения часто является распределенной вещью (разработчики разбросаны по всему миру работает над одним и тем же продуктом / проектом). ClearCase для этого определенно не подходит, потому что плохо подходит для работы в автономном режиме. Для выполнения извлечения (действия перед редактированием файла / папки) необходимо подключение к сети. Здесь вы можете использовать опцию взлома, но это скорее обходной путь как функция (вы в основном просто разблокируете файл в файловой системе). Если ваши сайты разработки находятся далеко от вашего сервера ClearCase, задержка регистрации / возврата может даже увеличиться настолько резко, что ее вообще нельзя будет использовать. Для этого есть обходные пути, такие как использование ClearCase Multisite (технология реплик SCM DB), но за это нужно доплачивать, и администрирование не является тривиальным.
Git как альтернатива
Хотя я большой поклонник + сторонник Open Source Я по-прежнему готов платить деньги за хорошее программное обеспечение. Но глядя на IBM-монстра ClearCase, я бы не стал вкладывать здесь свои деньги, у него есть все обсуждаемые недостатки, и, более того, IBM, похоже, не вкладывает деньги в существенное улучшение своего продукта. Недавно я посмотрел Git scm, который выглядит очень хорошо, особенно для его функций ветвления + слияния, где ClearCase имеет свои основные сильные стороны.
Эта информация взята из http://www.aldana-online.de/2009/03/19/reasons-why-you-should -stay-away-from-clearcase /
Абсолютный кошмар системы. Мне захотелось вернуться к VSS! (Не говоря уже о любой современной системе управления исходным кодом, такой как Subversion или Git!)
- Это slooooow .
- Если вы используете динамические представления и сеть выходит из строя, вы не сможете получить доступ к своей рабочей копии источника. Вы ничего не можете сделать, кроме сидеть и ждать , пока это будет исправлено.
- Если вы используете представления моментальных снимков , кажется, что вы постоянно сталкиваетесь с конфликтами и «взломанными» файлами, поэтому файлы в вашей рабочей копии никогда не будут такими же, как в исходном репозитории .
- Всякий раз, когда вы пытаетесь выполнить большое обновление или выполнить операцию , оно неизменно ОТКАЗЫВАЕТСЯ по той или иной причине, что требует от гуру ClearCase потратить несколько часов / дней выясняя это. Ах да, у вас должен быть преданный, штатный гуру ClearCase!
- Когда он терпит неудачу, вы часто не можете откатить операцию, так что вы застряли в выполняется операция, и разработчики заблокированы .
- Когда вы смотрите мимо красивых (?) значков, GUI очень плохой - вплоть до таких вещей, как невозможность изменить размер окон, чтобы увидеть полные пути к файлам!
- Их сотрудники службы поддержки очень неохотно что-либо исправляют. Их первый ответ всегда: « это сделано намеренно » и «Вы можете обойти это?» Если они в конечном итоге предоставят исправление (после долгих споров), это будет самое простое из возможных исправлений самой неотложной проблемы.
По сути, это медленное, сложное и чертовски ненадежное решение. О, и я упоминал , это смехотворно дорого ? Единственный способ, которым они могут продать его, - это поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда его не купит.
По сути, это медленное, сложное и чертовски ненадежное решение. О, и я упоминал , это смехотворно дорого ? Единственный способ, которым они могут его продать, - это поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда его не купит.
По сути, это медленное, сложное и чертовски ненадежное решение. О, и я упоминал , это смехотворно дорого ? Единственный способ, которым они могут продать его, - это поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда его не купит.
Если они в конечном итоге предоставят исправление (после долгих споров), это будет самое простое из возможных исправлений самой неотложной проблемы.По сути, это медленное, сложное и чертовски ненадежное решение. О, и я упоминал , это смехотворно дорого ? Единственный способ, которым они могут его продать, - это поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда его не купит.
Если они в конечном итоге предоставят исправление (после долгих споров), это будет самое простое из возможных исправлений самой насущной проблемы.По сути, это медленное, сложное и чертовски ненадежное решение. О, и я упоминал , это смехотворно дорого ? Единственный способ продать его - поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда его не купит.
Динамические просмотры. Должен восхищаться полностью функциональной полупрозрачной файловой системой.
Одним из больших преимуществ является то, что Интеллектуальная собственность всегда находится в корпоративной сети. Ноутбук может быть утерян / украден, а исходный код не окажется под угрозой.
Другой - мгновенный доступ к исходному коду и измененным файлам, не тратится времени на загрузку чего-либо.
Это хорошо служит той цели, которую он имеет.
Все, с чем я сталкивался, так или иначе связанное с ClearCase, неэффективно, уродливо, чрезмерно сложно, медленно, запутанно, дорого и неудобно.
Кажется, что она привлекает менеджеров и инженеров, которые ПРОСТО ПОЛУЧИЛИ ВСЕ НЕПРАВИЛЬНО.
Черт возьми, у IBM и Rational должны быть потрясающие продавцы, чтобы продавать такой дерьмовый продукт.
Возможно, худшее программное обеспечение из когда-либо созданных. Я не буду работать ни в одной фирме, которая использует что-либо рациональное. Помимо полного сбоя CC и частого перезапуска моей рабочей станции при динамических сборках. Что происходит, когда вы отправляете что-то в систему управления версиями, а CC делает то, что у него лучше всего, - сбой? Ваш код затем вставлен в потерянный + найденный, может быть, где-то сделана резервная копия? Нет, это ушло навсегда. Так что, если вы когда-нибудь окажетесь в ужасной ситуации использования этого гигантского дорогостоящего программного обеспечения, сохраните все дубликаты. Хорошая работа Rational / IBM. Способ зафиксировать самую важную часть системы контроля версий - надежность. Умри медленно.
Мой опыт в основном ограничен CC, CVS и SVN. В принципе, CC технологичен, готов к работе на предприятии и сравним по возможностям с любой современной VCS. Но у него есть несколько недостатков, которые делают его непригодным для использования в любой среде, ориентированной на людей. Для сред, ориентированных на процессы, он, вероятно, подходит больше, хотя я сомневаюсь, что такие среды подходят сами по себе. Может быть, в военном, космическом или медицинском программном обеспечении, я не знаю. В любом случае, я считаю, что даже для этих областей есть подходящие и более дружественные инструменты.
Помимо технических возможностей VCS, CC имеет несколько отличительных преимуществ:
- Динамические представления
- Хорошее дерево версий
- Триггеры
- Хорошее слияние версий, включая переименования
На мой взгляд, их использование ограничено, за исключением последнего, и они не компенсируют недостатки. Динамическое представление хорошо в теории, но не всегда доступно на практике. Дерево версий имеет гораздо меньшее применение в других VCS, в то время как в CC оно необходимо из-за разрастания ветвей (см. 6). Триггеры, как я знаю, очень подробные и способные, но я думаю, что для большинства практических задач достаточно SVN хуков. А теперь о недостатках, которые в основном касаются удобства использования:
- CC полностью провалился в смысле удобства использования для основной группы пользователей: для разработчиков. И это главная причина, по которой я считаю, что его никогда не следует использовать в любой среде, будь то корпоративная или нет. Даже если бы он был бесплатным, он все равно будет высасывать деньги вашей компании, тратя время ваших разработчиков и расстраивая их. Этот пункт взят из:
- "Check out-Check In" с подходом строгой блокировки - это контрпродуктивно, недружелюбно к рефакторингу и опасно в репозиториях с одной веткой разработки для нескольких разработчиков. Между тем, преимущества строгой блокировки ничтожно малы.
- Низкая производительность и высокая нагрузка
- Его фактически невозможно использовать удаленно без многосайтовости (из-за 2). Многосайтовость тоже стоит дорого. Клиент ClearCase Remote очень ограничен. У него даже нет
cleartool(до версии 7.1), не говоря уже о динамических представлениях. - Его едва ли можно использовать в автономном режиме. Динамические представления просто не работают. Представления моментальных снимков фактически доступны только для чтения, потому что вы не можете выполнить проверку без доступа к хранилищу (см. 1). Hijack - плохая опция, которая фактически означает, что CC отказывается от любой ответственности за захваченный файл. И CC не может показать вам разницу с предыдущей ревизией, когда вы не в сети. SVN способен показать разницу с предыдущей ревизией, даже находясь в автономном режиме.
- Слишком сложная модель, особенно с UCM: VOBs, PVOBs, Projects, streams, branches, views, deliver, update, load, restore, rebase, merge, baseline, check in, check out. Я думаю, что половина этих концепций просто излишни и не добавляют ценности, увеличивая при этом техническую и концептуальную сложность. Немногие разработчики понимают даже базовые вещи о CC.
- Распространение ветвлений. Например, репозиторий часто организуется с потоком на одного разработчика (из-за 1). Это просто не имеет смысла в SVN или большинстве других VCS.
- Отсутствие ревизий для всего репозитория. Ну, такие ревизии, как понятно, есть, они называются базовыми. Но когда я вижу ревизию какого-то файла и хочу получить снимок хранилища на момент ревизии этого файла, у меня возникнут проблемы. Мне придётся заниматься чёрной магией с config spec, чтобы создать представление снапшота, или как-то найти его через динамическое представление, если оно доступно.
- Дрянной пользовательский GUI. Дерево версий, даже будучи красивым, имеет посредственное удобство использования. Инструмент слияния просто убог. Другие "особенности": не изменяемые размеры окон, отсутствие инкрементального поиска в некоторых местах, интерфейс, ориентированный на мышь, внешний вид в стиле 1995 года, странный рабочий процесс, распределенный между Client и Project Explorer и т.д.
- CC провоцирует редкие и обширные check ins. Вы все знаете, что check ins должен быть небольшим и частым. Но разработчики обычно воздерживаются от дополнительных взаимодействий с CC, перехватывают файлы и работают в локальном VCS или даже вообще без VCS (что чаще всего, к сожалению). И вот, после двух недель разработки они начинают коммитить комлексную фичу, которая добавляет 20 файлов и затрагивает еще 20 файлов. Это длится день или два, потому что они захватили файлы и теперь нужно выполнить ручное слияние со всеми новыми изменениями из репозитория и разрешить все конфликты и несоответствия. Во время этого процесса код лежит не компилируемый, потому что несколько файлов успешно прошли проверку, а другие нет. И после этого он все еще не компилируется, потому что они забыли добавить еще 2 файла в CC.
- Это очень дорого
- Это очень сложно с точки зрения инфраструктуры и требует выделенных администраторов
- нет атомарных проверок
Начиная с новой версии 7.1 CC предоставляет атомарные проверки в качестве функциональности, ЕСЛИ вам это нравится. Лично я бы этого не хотел, но, видимо, некоторые люди видят в этом «существенную особенность». Я НИКОГДА не хотел бы иметь одну большую массу за раз, как своего рода массивную версию. Опять же ... если хочешь, просто включи.
так что ... больше не аргумент.
пункт «требуется специальный человек» и «это сложно» и т. Д.
Основная проблема при обнаружении этой проблемы заключается в том, что вы должны определить, хотите ли вы, чтобы управление конфигурацией выполнялось в вашей организации (что НЕ является управлением версиями). Управление конфигурацией похоже на управление проектом: даже без инструмента вы все равно можете управлять проектом, а без инструмента вы можете управлять конфигурацией. Многим людям сложно это понять, и многие люди думают, что Управление конфигурациями равнозначно инструменту, который версии источников программного обеспечения или чего-то еще ... (поэтому сравнение с подрывными версиями или другими системами управления ВЕРСИЯМИ)
ClearCase - это решение, созданное для использования в среде управления конфигурацией ERGO: есть менеджер конфигурации (как «есть менеджер проекта»).
Итак ... если в вашем представлении этот преданный человек должен управлять инструментом, я думаю, что что-то очень не так. На мой взгляд, есть специальный человек, который занимается управлением конфигурацией, который с точки зрения конечного пользователя появляется только тогда, когда есть проблема с инструментом, но считает это лишь 1% своей работы.
Итак, что вам нужно сделать (как и в любом другом программном проекте), вернитесь к своим требованиям и составьте список требований к тому, что ваша организация хочет от управления конфигурацией. И ДА, как и в любом другом программном проекте, у вас будут пользователи (например, разработчики), которые полностью не согласны с другими пользователями (например, с руководством) по определенным требованиям. В этом заключается ключ, imho, к некоторым реакциям, которые я здесь читал.
И ИМХО, если у вас есть список требований организации И менеджер конфигурации в смеси .... выбор довольно ясен (см. Также форум на www.cmcrossroads.com)
ClearCase - это не только инструмент для конечных пользователей, которые вводят свои источники под контролем версий, например subversion или git. Это только 1% причин, по которым менеджеру конфигурации действительно нужен зрелый инструмент управления конфигурацией.
И ... я думаю, что выбор CM-системы никогда не должен зависеть от разработчиков, равных с выбором правильного инструмента управления проектами или правильной CRM-системы. Разработчики являются конечными пользователями определенной части функциональных возможностей инструмента.
Администрирование. Мне пришлось запланировать несколько дневных простоев, чтобы выполнить обновления с 6 до 7 и переместить полумассивный (159 ГБ) VOBS со старого сервера в хранилище SAN. С такой системой, как git или svn + svk, это можно было сделать в мгновение ока, почти автоматически, без каких-либо последствий для пользователей - они никогда не заметят. Они не могли продвигать изменения вверх по течению, но могли продолжать работать. С ClearCase или необработанным SVN они находятся во власти сервера репозитория.
ClearCase UCM - отличный инструмент, мне он нравится, и я думаю, что можно сделать что-то, чтобы добавить подобную функциональность к SVN / mercurial / git / bzr - не то чтобы вы не можете реализовать это с помощью скриптов-перехватчиков, но это индивидуально для каждого сайта. UCM настолько распространен, что все это делают, но почти никто не отслеживает его в репозиториях. : - /