Здравствуйте, SkYtRiX, Вы писали:
SYR>Меня смущает, что многие среды разработок — Зенд, Эклипс — имеют встроенную поддержку цэвээс... при использовании другой системы придётся обновлять всё ручками... не страшно, но не так удобно
Да нет, под SVN есть куча плагинов под все эти системы и число их множится, а качество растет...
SYR>Получается, что CVS вообще бесперпективняк?
Ну, получается да. Просто ребята из CVS ушли в SVN и результат впечатляет..
Здравствуйте, CMM_CASE, Вы писали:
CMM>Не над так дешево пиарить продукт.
Это еще вопрос, у кого PR дешевле. Аргументация СС пока не впечатляет.
CMM>Был тут ответ meridian, но видимо кто то не понимает Ильфа&Петрова, посему его удалили )
Правда? Я думаю модераторам виднее, вышеупомянутый персонаж давно нарушил правила корректного разговора, видимо аргументация кончилась, а поливать грязью собеседников здесь не принято.
CMM>Смысл был такой, что каждый выбирает продукт под свои разработки
Это, конечно верно, но мы так и не услышали начальника транспортного цеха, для каких именно задачь, по его мнению, не подходят опенсорс продукты и чем же СС лучше. Он все больше оперировал терминами "большой проект", но что же под этим имелось ввиду осталось загадкой.
AVK>>Subversion выпускается не под GPL.
M>Вы ничего не путаете , так же ка и Merle ?
M>А так называемый вами Subversion позиционируется как опенсорс (http://subversion.tigris.org/faq.html), хотя права принадлежат CollabNet.
Елки-палки, тебе пытаются просто сказать что опенсорс != GPL лицензия
Читаем нижепроцитированный пункт взятый по приведенной выше ссылке и ищем хоть одно упоминание GPL, после чего становится ясно кто здесь что путает:
No, Subversion is open source / free software. CollabNet pays the salaries of several full-time developers, and holds the copyright on the code, but that copyright is an Apache/BSD-style license which is fully compliant with the Debian Free Software Guidelines. In other words, you are free to download, modify, and redistribute Subversion as you please; no permission from CollabNet or anyone else is required.
Здравствуйте, PPA, Вы писали:
PPA>Здравствуйте, _Art_, Вы писали: _A_>>5. Все изменения исхлодников санкционированны. Создаваемые разработчиками версии связаны с полученными заданиями. _A_>>6. У нас процесс подготовки билда и его тестирования полностью автоматизирован при помощи ClearQuest
_A_>>Таким образом в цепочке Поступивший запрос — Билд, в который вышла реализация запроса нет обрывов и можно проследить весь процесс. От и до.
PPA>А если нет задания? исходник трогать нельзя? PPA>У Вас понятие — рефакторинг существует? PPA>Например программист видет что херню написал, и решил переписать покрасивше, ему это не разрешается, т.к. нет задания?
Все у нас существует. Я не говорил о том, как это работает конкретно у нас. Я всего лишь перечислил возможности инструмента и привел пример их использования.
На самом деле все зависит от политики, которая действует в отделе разработки и от степени формализации процесса. Между двумя полюсами Полный хаос. Все правят что хотят и когда хотят и ни байта нельзя изменить без соотвтствующей санкции существует еще бесконечность возможных вариантов. Та же интеграция ClearCase с ClearQuest позволяет задать этот уровень, а именно, есть следующие варианты:
1. Вы ничего не указываете при checkout
2. Вы можете но не обязаны выбрать задание, к которому относится ваша работа при checkout.
3. Вы ничего не указываете при checkin
4. Вы можете но не обязаны выбрать задание, к которому относится ваша работа при checkin.
5. Вы обязаны указать задание при checkin
Кроме того, могут быть заданы бренчи, элементы, типы элементов и некоторые другие параметры, для которых данные правила будут действовать.
И это базовая интеграция. А она может быть доработана вами при необходимости. Вы можете определить к примеру роли людей в проекте. Можно ввести разделение на подпроекты и для каждого из них установить собственные правила и так далее и так далее. Идти, как здесь уже много раз говорилось, нужно не от возможностей инструмента, и не подстраивать свой процесс под инструмент, а инструмент подстраивать под процесс, который вы хотите построить. Все зависит от ваших потребностей.
PPA>От кого приходят эти задания?
Это тоже определяется политикой. Может только от президетна компании, а может и вы сами можете создать задание. Для чего? Очень просто. Например: по ходу разработки вы документироуете собственные действия. В дальнейшем можно легко сгенерировать отчет о собственной деятельности за некоторый период времени. Можно выяснить причину определенных изменений и еще много чего. Я уже говорил о прозрачности процесса. Ваша работа прозрачна для Вас, для Вашего руководства, а может быть и для всех сотрудников компании. Опять таки, зависит от политики.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
А>>А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке" WH>Ну чтоже давайте поговорим об этом. А>>Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие: А>>1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования. WH>То что они способны работать с одним участком кода вовсе не значит что они должны работать с одним участком кода.
Почему же нет? Очень даже может быть. Все зависит от культуры отдела, от принципов работы. Почему Вы пытаетесь задать строго определенные догмы, которым должны следовать все разработчики? Это может не быть обычным явлением в компании. Но в некоторых ситуациях необходимость в этом может возникнуть.
Привожу пример: два разработчика знакомы с некоторым участком кода, так как разработали его вместе. К примеру в процессе парного программирования кстати интересно узнать, вы отвергаете данную практику?. Проходит некоторое время, и эти два программиста занимаются различными задачами. При этом эти задачи затрагивают именно этот участок кода. И не надо говорить что это плохая архитектура! Возможно это именно та ситуация, когда один разработчик ведет работу по основной деятельности, а другой — исследовательскую работу, которая в последующем вполне может быть проинтегрирована в ствол проекта. И что вы предлагаете делать? ждать одному из них, когда второй закончит работу с данным исходником?
WH>Я считаю что одновременая правка одного файла разными людьми ситуация аварийная. Ни одного аргумента в пользу того что такая практика оправдана и дает какието преймущества я так и не услышал.
У кого это может привести к катастрофе. Но у кого то это срабатывает, поверьте
WH>То что нормальные VCS могут это разруливать это вопрос отдельный.
Какой смысле реализовывать фукнцию, если она однозначно (по вашему мнению приводит к катастрофе)? И в чем же отдельность вопроса наличия функции параллельной разработки от непосредственно использования данной возможности?
А>>2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы). WH>Иследовательская работа это вопрос совершенно отдельный. В этом случае делается бранч и там уже идут изменения. Но это уже не копание в одном файле, а в другой версии проекта. А мерж того что наиследовал этот программист с остальным проектом процесс в любом случае не тривиальный и может привести к серьезным конфликтам (в зависимости от глубины результатов исследования).
Не понял. Как же это так? Иследовательская работа может затрагивать тот же файл, что и основная! Да хоть один и тот же программист может работать сразу над двумя задачами, которые затрагивают один и тот же файл.(если уж вы так отвергаете возможность двух разработчиков иметь понятие об одном исходнике). Параллельно. Одновременно! Первые 4 часа рабочего времени — основная работа. Вторые 4 часа — исследовательская. И причем здесь бедный архитектор?
А>>3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна. WH>Вот это я что-то не понял
Я имел ввиду, что необходимость в параллельной разработке может возникнуть по причине отсутствия стабильной версии в момент времени, программист хочет выполнить свою работу. А эта работа затрагивает файл, который является причиной нестабильности. Тогда программист использует для своей работы последнюю СТАБИЛЬНУЮ версию файла. А параллельно с этим последняя НЕСТАБИЛЬНАЯ версия данного файла доводится до ума. После того, как обе работы выполнены, поизводится мердж.
По сути это еще один пример
А>>Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов. WH>Тут нужно определиться с тем что является паралельной разработкой, а что нет. А>>Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки! WH>Именно это я и говорил. Нечего двум программерам делать в одном файле. А связь с архитектурой тут такая что при плохой декомпозиции зоны ответственности разных программеров начинают пересекаться что приводит к необходимости писать в один фаил. А декомпозиция проекта на высоком уровне это как ни крути работа архитектора. И если он это сделал плохо то именно его и надо бить.
Мой ответ содержится в том, что я написал выше.
WH>ЗЫ SVN умеет и мержить и делать бренчи.
Замечательно я только рад
Здравствуйте, SkYtRiX, Вы писали:
SYR>Меня смущает, что многие среды разработок — Зенд, Эклипс — имеют встроенную поддержку цэвээс... при использовании другой системы придётся обновлять всё ручками... не страшно, но не так удобно SYR>Получается, что CVS вообще бесперпективняк?
Для Eclipse есть плагин для SVN, Subclipse. Качество, правда, местами хромает, но в целом вполне нормально работает.
Здравствуйте, WolfHound, Вы писали:
WH>То что они способны работать с одним участком кода вовсе не значит что они должны работать с одним участком кода. WH>Я считаю что одновременая правка одного файла разными людьми ситуация аварийная. Ни одного аргумента в пользу того что такая практика оправдана и дает какието преймущества я так и не услышал.
Попробую привести пару примеров...
— Рефакторинг. Ну например, мне надо везде глобально поменять имя класса.
— Баг фикс. Мне время от времени надо править не мой файл.
Я правлю этот файл и не жду когда хозяин файла будет готов к такой правке.
На следующий день хозяин файла сделает rebase и получит мои изменения.
Если надо будет, то смерджит эти изменения ручками.
Кстати, в ситуациях, когда кто-то правит чужой файл,
хозяин файла автоматически получает уведомление.
В СС с UCM кстати, все девелоперы сидят на своих "бранчах" и параллельного
редактирования файлов на самом деле нету.
Каждый деверопер сидит в своей песочнице и никто никому не мешает.
Когда девелопер завершает кусок на своей ветке,
то он "мерджит" свой кусок на основную ветвь.
Время от времени (я делаю это каждое утро) надо делать update baseline.
Тем самым девелопер обновляет свою ветку и получает последнюю версию кода,
которая успешно "сбилдилась" и прошла юнит тесты.
Здравствуйте, CMM_CASE, Вы писали:
CMM>...starteam (нет ср-в моделирвания и тестирования)
UML-моделирование: Together for VS.NET, Together Architect (Control Center), Together Designer, Together for JBuilder, Together for Eclipse/WSAD/SAP NetWeaver.
Тестирование: производительности — OptimizeIt Profiler for .Net, OptimizeIt Suite for Java, OptimizeIt ServerTrace — для J2EE. Функциональное etc — интеграция (синхронизация) с Mercury TestDirector, интеграция с продуктами Segue.
Ой. извиняюсь. Да, слегка напутал. Спасибо, что поправили. Да и перечислять все возможные варианты интеграции не хотелось.
Кстати Clear Quest тоже интегрируется с Visial Studio. Покрайней мере, я могу все баги просматривать прямо из VS.
Я смотрю вы много работали с CC. Может быть подскажете как добавить под контроль рекурсивно сразу несколько вложенных папок и файлов
Здравствуйте, alex-consult, Вы писали:
AC>для рекурсивной постановки есть специальные команды СС AC>Clearexport_ffile AC>clearfsimport AC>ccimportwizard
AC>очень эффективные команды. Просто о них никто не знает, так как НЕ СЛУШАЮТ КОНСУЛЬТАНТОВ
Ага. Эти команды я нашел. Но... ccimportwizard — как я понял не может положить рекурсивно каталоги в тот девелоперский стрим в котором я работаю.
А вот clearfsimport — я не понимаю как ему указать target-VOB-directory (вообще не совсем понятно, как его указывать). У меня есть проект project1, два VOB — projects и sources. В проетке два стрима один стрим интеграции другой девелоперский. Я хочу в девелоперский стрим добавить структуру каталогов. Какой я должен записать параметр target-VOB-directory у команды clearfsimport.
Здравствуйте, NickSm, Вы писали:
NS>Здравствуйте, alex-consult, Вы писали:
AC>>для рекурсивной постановки есть специальные команды СС AC>>Clearexport_ffile AC>>clearfsimport AC>>ccimportwizard
AC>>очень эффективные команды. Просто о них никто не знает, так как НЕ СЛУШАЮТ КОНСУЛЬТАНТОВ
NS>Ага. Эти команды я нашел. Но... ccimportwizard — как я понял не может положить рекурсивно каталоги в тот девелоперский стрим в котором я работаю.
ОК. С каким СС вы работаете? СС LT + UCM?
Использую SVN в "нормальных" проектах уже 3-й год. До этого пользовался SSF ( фуфло ) и CVS ( тоже мрачно в сравнении с SVN ).
AC>Ответ будет страниц на 20. Если вы не понимаете зачем нужна параллельная разработка, значит ваш проетк не дошел до нее. Значит и сознание не дошло.
Много болтовни когда толкут воду в ступе... Параллельная разработка не подразумевает редактирование одних и тех же СТРОК в исходниках. Все остальные случаи параллелизма SVN разруливает отлично.
AC>Я уже 5 лет занимаюсь тем, что перевожу "дозревшие" компании на более высокий уровень. Слава богу, что в полседние годы уже идут люди не CVS и сурсейва, а с PVCS, где тоже есть и сборка и праллельное ветвление....
ГЫЫЫЫ Спасибо, мы уж как-нить без таких "поднимателей" обойдемся, ОК ?
AC>У меня к вам вопрос:
Хоть и не ко мне, отвечу
AC>Предствавим, что у вас была версия файла main.cpp... через какое то время нашли в старой версии ошибку. Еее нужно исправить. Напишите, как вы ее будете исправлять в SVN
ЛЕГКО И НЕПРИНУЖДЕННО. Или Вам конкретные команды привести? Или что?? В ЧЁМ собственно заключается вопрос? Если почитаете-таки доку по SVN, ищите слова "branches" и "tags" — популярно всё обсказано на чистом аглицком
Здравствуйте, LeeMouse, Вы писали:
LM>ЛЕГКО И НЕПРИНУЖДЕННО. Или Вам конкретные команды привести? Или что?? В ЧЁМ собственно заключается вопрос? Если почитаете-таки доку по SVN, ищите слова "branches" и "tags" — популярно всё обсказано на чистом аглицком
Плюс СС в том, что там уже ушли от прямого использования "branches" и "tags".
Это все скрыто. tags еще немного видно под соусом baseline ну а "бранчи"
большинство и не видит в явном виде.
Здравствуйте, bkat, Вы писали: LM>>ЛЕГКО И НЕПРИНУЖДЕННО. Или Вам конкретные команды привести? Или что?? В ЧЁМ собственно заключается вопрос? Если почитаете-таки доку по SVN, ищите слова "branches" и "tags" — популярно всё обсказано на чистом аглицком
B>Плюс СС в том, что там уже ушли от прямого использования "branches" и "tags".
В SVN не уходили, там никогда небыло прямого использования веток и тэгов.
"branches" и "tags" это просто общепринятые названия каталогов в которые копируются срезы ствола разработки.
B>Это все скрыто.
В SVN все открыто. и большой вопрос что является плюсом.
B>tags еще немного видно под соусом baseline
причем тут соус я не понял
но тэг он и в африке тэг — фиксация дерева исходников в определенном состоянии.
в SVN это делается командой copy в любое удобное место, которое потом не забудешь
а вот как можно тег видеть _немного_ я
B>ну а "бранчи" B>большинство и не видит в явном виде.
от того, что он видит это в неявном виде, суть контроля версий не меняется,
вероятно, в CC общедоступные понятия назвали другими словами.
Здравствуйте, PPA, Вы писали:
B>>Это все скрыто.
PPA>В SVN все открыто. и большой вопрос что является плюсом.
Это скрыто, но значит, что недоступно.
Кому хочется ковыряться в configspec, тот может это делать.
Просто мало кому это надо, кроме администраторов.
P.S.
В общем поставлю я все же дома SVN.
Ато блин получается что я не знаю SVN, а ты явно не знаком с СС
и мы пытаемся друг другу что-то доказать.
Ладно бы еще просто каждый рассказывал о том, что знает.
Дак еще эмоции приплетаются.
Мы уже победили, просто это еще не так заметно...
