Сдается мне, что мало кто ее прочитал до конца. Потому как после каждого нажатия на ссылку с описанием какого-либо пункта страничка уезжает вверх и ее приходится скроллить заново. По моему скромному мнению, заставлять пользователя делать это 68 раз — это форменное издевательство.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Здравствуйте, NickSm, Вы писали:
NS>И ГЛАВНОЕ. Почему-то никто об этом не говорил. NS> Очень хорошая интеграция с программами разработки ПО и с системами поддержки разработки ПО.
Здравствуйте, meridian, Вы писали:
M>А так называемый вами Subversion позиционируется как опенсорс
Мы прекрасно знаем что из себя представляет Subversion и как он позиционируется.
Вы можете внятно сказать, чем Вас не устраивает опенсорс и какой смысл Вы вкладываете в это термин?
CollabNet осуществляет разработку и поддержку Subversion, в поставку продукта входят исходники, что Вас не устраивает в этой схеме?
M>Так что, товарищи, почитайте FAQ на их сайте, хоть будете знать , с чем работаете
Не надо нам рассказывать давно известные вещи, делитесь радостью открытия с кем-нибудь другим..
Здравствуйте, meridian, Вы писали:
M>Извиняю, читайте предэд. посты, где писал, что не имеются ввиду впоследствии открытые коды M>К тому же написано "...в частности ...", сиречь как одна из причин.
Позволю себе некоторое занудство, но боюсь, что подобные отмазки здесь не пройдут. Во-первых имелось ввиду, что Microsoft в принципе не брезгует open source разработками, не открытыми в последствии кодами, а именно проектами с изначально открытыми исходниками, например FlexWiki.
А во-вторых, предложенная причина выглядит довольно нелепо, даже как одна из причин, в силу того, что, как я уже писал ранее, на деньги потраченные на CC большая корпорация, с хорошей вероятностью, могла скупить весь CollabNet на корню.
Здравствуйте, SkYtRiX, Вы писали:
SYR>Гы, я так понял, что CVS уже за систему не считают и не пользуют, да?
Ну, почему, считают и даже используют, но SVN лучше...
SYR> А что, SVN по сравнению с ней имеет лучшие показатели?
Угу.
Уважаемые, неужели вы думаете, что Rational, то есть IBM что то платит за продвижение своих продуктов?
Если бы она платила, то из всех форумов удалялись бы нелестные отзывы о rational
Наша компания — системный интегратор. Это значит, что мы В РАВНОЙ СТЕПЕНИ предлагаем своим клиентам rational, telelogic и mercuri...
То есть мы даем выбор. И когда клиент решает выбрать платформу мы ему помогаем в этом...
К сожелению, на Российском рынке кроме нас так НИКТО не поступает... Поэтому ВАШИ упреки я отметаю как беспочвенные
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, SkYtRiX, Вы писали:
SYR>>Гы, я так понял, что CVS уже за систему не считают и не пользуют, да? M>Ну, почему, считают и даже используют, но SVN лучше...
SYR>> А что, SVN по сравнению с ней имеет лучшие показатели? M>Угу.
Меня смущает, что многие среды разработок — Зенд, Эклипс — имеют встроенную поддержку цэвээс... при использовании другой системы придётся обновлять всё ручками... не страшно, но не так удобно
Получается, что CVS вообще бесперпективняк?
Здравствуйте, SkYtRiX, Вы писали: SYR>Меня смущает, что многие среды разработок — Зенд, Эклипс — имеют встроенную поддержку цэвээс... при использовании другой системы придётся обновлять всё ручками... не страшно, но не так удобно
Что обновлять то? и что значит ручками?
SYR>Получается, что CVS вообще бесперпективняк?
О какой перспективе может идти речь, если cvs не подерживает историю каталогов?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, meridian, Вы писали:
M>>А так называемый вами Subversion позиционируется как опенсорс M>Мы прекрасно знаем что из себя представляет Subversion и как он позиционируется. M>Вы можете внятно сказать, чем Вас не устраивает опенсорс и какой смысл Вы вкладываете в это термин? M>CollabNet осуществляет разработку и поддержку Subversion, в поставку продукта входят исходники, что Вас не устраивает в этой схеме?
M>>Так что, товарищи, почитайте FAQ на их сайте, хоть будете знать , с чем работаете M>Не надо нам рассказывать давно известные вещи, делитесь радостью открытия с кем-нибудь другим..
Мы Николай II ?
Merle, Не надо говорить за всех, привыкайте отвечать только за себя и отвечайте за свои слова.
Это, собственно, показывает ваш уровень не с лучшей стороны.
meridian кажется ясно ответил AndrewVK, вам же заодно, может быть Вы не знаете — такое тоже бывает.
Да и к тому же он раньше писал, что не знаком совсем с Subversion, причем потом потратил свое время для ознакомления с продуктом и указал AndrewVK, что он неправ.
Это же вроде пост "AndrewVK:"Subversion выпускается не под GPL." ? и "Советую ознакомится с GPL."
Еще и советует.. прикольно
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, SkYtRiX, Вы писали:
SYR>>Гы, я так понял, что CVS уже за систему не считают и не пользуют, да? M>Ну, почему, считают и даже используют, но SVN лучше...
SYR>> А что, SVN по сравнению с ней имеет лучшие показатели? M>Угу.
Не над так дешево пиарить продукт.
Было бы правильнее сказать "для меня лучше", в крайнем случае "для нашей команды"
Был тут ответ meridian, но видимо кто то не понимает Ильфа&Петрова, посему его удалили )
Смысл был такой, что каждый выбирает продукт под свои разработки
Здравствуйте, Yampolski_Nikita, Вы писали:
Y_N>Привет всем.
Y_N>Господа, интересует сабж. Т.е. что вы считаете наилучшим инструментом контроля версий ? Что вы используете ? Почему ? Интересует функциональность, мультиплатформенность, гибкость — такие вот параметры.
Y_N>Прошу высказаться.
Y_N>Спасибо заранее.
Прочитав весь форум вы так и не найдете ответа на ваш вопрос, т.к. каждый кулик свое болото хвалит.
Зайдите на www.cmcons.com, там есть сравнение нескольких продуктов, плюс вам нужно будет сравнить продукты, обозначенные в форуме.
Исходите из своих задач разработки и затрат на внедрение и обслуживание.
Если нужен продукт, поддерживающий весь процесс разработки, то наверно clearcase, telelogic(нет вроде ср-в тестирования), starteam (нет ср-в моделирвания и тестирования), если команда небольшая, то можно рассмотреть продукты других фирм, менее дорогих
Re[3]: VSS vs CVS vs PVCS vs ClearCase (???)
От:
Аноним
Дата:
26.02.05 16:53
Оценка:
Здравствуйте, NickSm, Вы писали:
NS>И ГЛАВНОЕ. Почему-то никто об этом не говорил. NS>Очень хорошая интеграция с программами разработки ПО и с системами поддержки разработки ПО. NS>Естественно каждая со своими. Т.е. StartTeam с CaliberRM и JBuilder, а ClearCase с requisitePro, ClearQuest и Visual Studio NET (с последним интеграция очень хороша, попробуйте сразу поймете, что хоть это и не главное но очень важное преимущество).
Вы немного напутали в плане интеграции.
Было сказано что интеграция инструментов — это очень важно. Я это полностью поддерживаю и считаю это большим приемуществом компании Rational.
Коротко об интеграции инструментов:
1. ClearQuest — RequisitePro
Если применять ClearQuest в качестве "корзины" запросов, то в дальнейшем данные запросы можно связать с требованиями в RequisitePro.
2. RequisitePro — ClearQuest
Проработанные требования могут быть связаны с заданиями в ClearQuest. При помощи ClearQuest произходит непосредственное управление процессом внесения изменений в проект, т.е. реализацией требований.
3. ClearQuest — ClearCase
Здесь все просто. Если вы решите использовать данный вид интеграции, вы сможете связать изменения, производимые в исходниках (версии элементов) с заданиями, которые назначены вам в ClearQuest.
4. ClearCase — Visual Studio
Здесь все понятно. ClearCase интегрируется со средством разработки. Кстати существует также интеграция и для борландовских инструментов. Проверено, вирусов нет . Просто автор предыдущего поста немного перепутал ClearCase с ClearQuest-ом, и я решил исправить эту ошибку.
5. ClearQuest — TestManager
В двух словах: тестскрипт выявил ошибку — в ClearQuest автоматически создается запись об ошибке с подробнейшим ее описанием.
Я могу еще много рассказать о всех существующих видах интеграции, но лучше просто перечислю
ClearQuest — MS Project
RequisitePro — MS Project
TestManager — RequisitePro
Средства тестирования — MSDEV
А сколько своих интеграций можно написать
А еще ни слова не было сказано об инструменте генерации документов и отчетов
А это Crystal Reports и SoDA, которая проинтегрирована практически со всеми средствами Rational.
Конечно же это не означает, что использовать нужно все инструменты и все виды интеграции. Это сродни точке зрения о внедрении некоторого процесса разработки. Зачем это делать, если можно взять нужную часть, изменить ее под собственные нужны и использовать.
Наша компания конечно же не использует ВСЕ эти способы. По мере необходимости мы применяем те или иные. Бывает даже, что некоторую интеграцию мы используем в фиксированный рпомежуток времени для решения определенных организационных проблем.
Тоже самое с инструментами. При помощи инструментов можно упростить, улучшить качество процесса разработки. Думать что инструмент и процесс — одно и тоже — заблуждение.
Могу немного рассказать о нашей компании. Изначально в качестве средства управления версиями мы использовали .... зашаренную папку .
Потом перешли на SourceSafe. Долгое время мы работали с этим замечательным инструментом. Но в определенный момент нам понадобилась возможность "параллельной разработки". По рекомендации был выбран ClearCase. Так до сих пор на нем и живем. К сожалению у меня нет опыта использования других инструментов, и я не могу чтолибо добавить по этому поводу. ClearCase нас полностью удовлетворяет. Возможно мы перейдем на другой инструментарий. Если это случится, то по причине высокой цены Rational.
А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке"
Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие:
1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования.
2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы).
3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна.
Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов. Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки!
Здравствуйте, NickSm, Вы писали:
NS>И ГЛАВНОЕ. Почему-то никто об этом не говорил. NS>Очень хорошая интеграция с программами разработки ПО и с системами поддержки разработки ПО. NS>Естественно каждая со своими. Т.е. StartTeam с CaliberRM и JBuilder, а ClearCase с requisitePro, ClearQuest и Visual Studio NET (с последним интеграция очень хороша, попробуйте сразу поймете, что хоть это и не главное но очень важное преимущество).
Вы немного напутали в плане интеграции.
Было сказано что интеграция инструментов — это очень важно. Я это полностью поддерживаю и считаю это большим приемуществом компании Rational.
Коротко об интеграции инструментов:
1. ClearQuest — RequisitePro
Если применять ClearQuest в качестве "корзины" запросов, то в дальнейшем данные запросы можно связать с требованиями в RequisitePro.
2. RequisitePro — ClearQuest
Проработанные требования могут быть связаны с заданиями в ClearQuest. При помощи ClearQuest произходит непосредственное управление процессом внесения изменений в проект, т.е. реализацией требований.
3. ClearQuest — ClearCase
Здесь все просто. Если вы решите использовать данный вид интеграции, вы сможете связать изменения, производимые в исходниках (версии элементов) с заданиями, которые назначены вам в ClearQuest.
4. ClearCase — Visual Studio
Здесь все понятно. ClearCase интегрируется со средством разработки. Кстати существует также интеграция и для борландовских инструментов. Проверено, вирусов нет . Просто автор предыдущего поста немного перепутал ClearCase с ClearQuest-ом, и я решил исправить эту ошибку.
5. ClearQuest — TestManager
В двух словах: тестскрипт выявил ошибку — в ClearQuest автоматически создается запись об ошибке с подробнейшим ее описанием.
Я могу еще много рассказать о всех существующих видах интеграции, но лучше просто перечислю
ClearQuest — MS Project
RequisitePro — MS Project
TestManager — RequisitePro
Средства тестирования — MSDEV
А сколько своих интеграций можно написать
А еще ни слова не было сказано об инструменте генерации документов и отчетов
А это Crystal Reports и SoDA, которая проинтегрирована практически со всеми средствами Rational.
Конечно же это не означает, что использовать нужно все инструменты и все виды интеграции. Это сродни точке зрения о внедрении некоторого процесса разработки. Зачем это делать, если можно взять нужную часть, изменить ее под собственные нужны и использовать.
Наша компания конечно же не использует ВСЕ эти способы. По мере необходимости мы применяем те или иные. Бывает даже, что некоторую интеграцию мы используем в фиксированный рпомежуток времени для решения определенных организационных проблем.
Тоже самое с инструментами. При помощи инструментов можно упростить, улучшить качество процесса разработки. Думать что инструмент и процесс — одно и тоже — заблуждение.
Могу немного рассказать о нашей компании. Изначально в качестве средства управления версиями мы использовали .... зашаренную папку .
Потом перешли на SourceSafe. Долгое время мы работали с этим замечательным инструментом. Но в определенный момент нам понадобилась возможность "параллельной разработки". По рекомендации был выбран ClearCase. Так до сих пор на нем и живем. К сожалению у меня нет опыта использования других инструментов, и я не могу чтолибо добавить по этому поводу. ClearCase нас полностью удовлетворяет. Возможно мы перейдем на другой инструментарий. Если это случится, то по причине высокой цены Rational.
А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке"
Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие:
1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования.
2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы).
3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна.
Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов. Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки!
Хочу добавить причину, по которой возможность интеграции инструментов, предназначенных для различных целей является действительно ценной.
Обеспечивается прозрачный процесс разработки.
К примеру у нас в компании я вижу это примерно так (к сожалению это еще в полной степени работает, но все же...):
1. Запрос на изменение поступает и заносится в базу ClearQuest
2. На основе запросов формируются требования, при этом они связаны с запросами.
3. Требования преобразуются в задания и поступают обратно в ClearQuest в преобразованном виде.
4. При помощи ClearQuest отслеживается процесс работы над заданием
5. Все изменения исхлодников санкционированны. Создаваемые разработчиками версии связаны с полученными заданиями.
6. У нас процесс подготовки билда и его тестирования полностью автоматизирован при помощи ClearQuest
Таким образом в цепочке Поступивший запрос — Билд, в который вышла реализация запроса нет обрывов и можно проследить весь процесс. От и до.
Здравствуйте, CMM_CASE, Вы писали: SYR>>> А что, SVN по сравнению с ней имеет лучшие показатели? M>>Угу.
CMM>Не над так дешево пиарить продукт. CMM>Было бы правильнее сказать "для меня лучше", в крайнем случае "для нашей команды"
Если Ваша команда не использует бранчи, и ей не нужно гарантированно
восстанавливать дерево своих проектов, то cvs вполне для этого годится.
CMM>Был тут ответ meridian, но видимо кто то не понимает Ильфа&Петрова, посему его удалили ) CMM>Смысл был такой, что каждый выбирает продукт под свои разработки
http://osdir.com/Article203.phtml
svn является развитием cvs.
Выбрать в 2005 году заведомо худшее и морально устаревшее решение при одинаковой стоимости
может только человек, который вообще слабо ориентируется в том, что такое vcs,
и зачем оно ему нужно.
таким лучше уж по старинке бэкапить исходники по пятницам на cd-r
Здравствуйте, _Art_, Вы писали: _A_>5. Все изменения исхлодников санкционированны. Создаваемые разработчиками версии связаны с полученными заданиями. _A_>6. У нас процесс подготовки билда и его тестирования полностью автоматизирован при помощи ClearQuest
_A_>Таким образом в цепочке Поступивший запрос — Билд, в который вышла реализация запроса нет обрывов и можно проследить весь процесс. От и до.
А если нет задания? исходник трогать нельзя?
У Вас понятие — рефакторинг существует?
Например программист видет что херню написал, и решил переписать покрасивше, ему это не разрешается, т.к. нет задания?
От кого приходят эти задания?
... << RSDN@Home r(345)>> <<winamp::Therion — Eye Of Shiva>>
Здравствуйте, <Аноним>, Вы писали:
А>А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке"
Ну чтоже давайте поговорим об этом. А>Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие: А>1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования.
То что они способны работать с одним участком кода вовсе не значит что они должны работать с одним участком кода.
Я считаю что одновременая правка одного файла разными людьми ситуация аварийная. Ни одного аргумента в пользу того что такая практика оправдана и дает какието преймущества я так и не услышал.
То что нормальные VCS могут это разруливать это вопрос отдельный. А>2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы).
Иследовательская работа это вопрос совершенно отдельный. В этом случае делается бранч и там уже идут изменения. Но это уже не копание в одном файле, а в другой версии проекта. А мерж того что наиследовал этот программист с остальным проектом процесс в любом случае не тривиальный и может привести к серьезным конфликтам (в зависимости от глубины результатов исследования). А>3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна.
Вот это я что-то не понял А>Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов.
Тут нужно определиться с тем что является паралельной разработкой, а что нет. А>Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки!
Именно это я и говорил. Нечего двум программерам делать в одном файле. А связь с архитектурой тут такая что при плохой декомпозиции зоны ответственности разных программеров начинают пересекаться что приводит к необходимости писать в один фаил. А декомпозиция проекта на высоком уровне это как ни крути работа архитектора. И если он это сделал плохо то именно его и надо бить.
ЗЫ SVN умеет и мержить и делать бренчи.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CMM_CASE, Вы писали:
CMM>Мы Николай II ?
Мы — это, я и AVK, поскольку отвечали нам.
CMM>Merle, Не надо говорить за всех, привыкайте отвечать только за себя и отвечайте за свои слова.
Упаси байт, но прежде чем учить, не плохо было бы отвечать непосредственно на реплики собеседника, а не на то, что Вы домыслили за него. Это помогает держаться в рамках и не переходить на личности.
К тому же для подобных реплик есть модераторы, держите себя в руках, здесь непринято вести себя некорректно.
CMM>Это, собственно, показывает ваш уровень не с лучшей стороны.
Уровень чего?
CMM>meridian кажется ясно ответил AndrewVK, вам же заодно, может быть Вы не знаете — такое тоже бывает.
Какое бывает?
CMM>Да и к тому же он раньше писал, что не знаком совсем с Subversion, причем потом потратил свое время для ознакомления с продуктом и указал AndrewVK, что он неправ.
Если он не знаком с продуктом, то зачем он тогда принялся его заочно осуждать? Он не ознакомился с продуктом, он прочитал FAQ и сделал оттуда выводы не имеющие отношения к делу, так что лучше бы уж свое время не тратил.
Для консультанта, коим он является, было бы не плохо иметь большую четкость изложения и внятность аргументации, а то пока подобные консультации идут только во вред продукту.
Да, и в чем, по Вашему, был не прав AVK? Subversion действительно выпускается не под GPL, а под AFS на что AVK имел несчастье указать и мне непонятно, каким образом бурная реакция господина meridian является указанием на неверность совершенно справедливого замечания AVK.
Мы уже победили, просто это еще не так заметно...
