Всем добрый день.
Предлагаю обсудить проблему контроля версий исходного кода.
Интересно узнать мнения людей, которые уже пользуются подобными системами об
их предпочтениях в этом вопросе: какую систему лучше использовать, какие
проблемы поджидают и т.д.
Существуют ли инструменты, позволяющие интегрировать эти системы с Delphi.
Лично меня интересует случай когда:
- 1) Несколько проектов(> 15) ведут несколько программистов(>10).
- 2)Почти все проекты на Delphi(но используется и Visual Studio и т д.)
Aleksei Pastutsan
Всего в теме 111 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
- Case-средства, средства коллективной разработки и т.п.
- О CASE средствах.
- Change Manager DS
- О системах контроля ошибок
- Альтернативная система контроля версий.
- Системы контроля версий. Средства управления проектом.
| № 61 23-04-2003 15:14 |   |
| № 60 23-04-2003 15:12 | |
Ответ на »сообщение 59« (Andrew Semack)
___________________________
Забыл. :) Информация к размышлению от знакомого, работающего в MS: MS в своей разработке не использует VSS.
Напрашивается риторический вопрос: ПОЧЕМУ? :)
Это не так интересно. Интереснее другой вопрос — а что они используют?
| № 59 23-04-2003 14:33 | |
Ответ на »сообщение 57« (Сергей Тарасов)
___________________________
При корпоративной разработке,
Забыл. :) Информация к размышлению от знакомого, работающего в MS: MS в своей разработке не использует VSS.
Напрашивается риторический вопрос: ПОЧЕМУ? :)
| № 58 23-04-2003 14:22 | |
Ответ на »сообщение 57« (Сергей Тарасов)
___________________________
Да, инструмент куплен, не VS, а MSDN-подписка, но это к теме не относится.
Проехали. Замечу, что VSS не входиит в состав подписки MSDN, а в VS или в VS .NET :)
То что вы описали - пример классического "бардака" :) Подумайте, зачем тогда вообще нужна VCS, если каждый разработчик работает в своей ветке ? :)
Позвольте не согласится. Если Вы считаете, что я работаю в "бардаке", Вы не правы. Рекомендую ознакомится с схемой ClearCase UCM. Именно её мы и используем. Там потоковая работа, организована именно на брэнчах. Welcome to Interface LTD. Там есть некоторые статьи по ClearCase, которые раскрывают принципы работы в потоках. Ключевые слова для поисковиков: ClearCase UCM, Integration Stream, Development Stream, Delivering, Rebasing, Baseline.
"Сплошь и рядом" другая схема - разработка идет в одной ветке. Над основной версией.
Я эту схему проходил. Это для маленьких команд и мелких проектов.
Бранч нужен совершенно для определенных целей, например, для выпуска хотфиксов или проверки возможности использования новых модулей перед введением их в основную продакшн-версию.
Кто Вам это сказал? Еще раз, читаем про ClearCase UCM или Seapine Surround SCM (htpp:// www.seapine.com).
Технических проблем с блокировками не существует - в VSS есть такой флажок в настройках - allow multiple checkouts, вы его, видимо, не заметили.
Во! Это называетс Резервированием. Может быть и не досмотрел. Но это не заменит брэнчивание.
При этом никто не отменяет проблем, возникающих при использовании такой системы блокировок в ЛЮБОЙ системе, а именно необходимости постоянно разрешать конфликты - самый неприятный источник ошибок и потерь.
И нет. Если система не может автоматически решить конфиликт, то она должна предложить это сделать пользователю. На самом деле, автомат не справляется очень редко. И на решение конфликта уходит не более 1-й - 2-х минут. Если конечно DFM у вас не в бинарниках :)
Поэтому использовать данный режим разработки следует только в случаях, когда это действительно требуется. Скажем, при разработке на sourceforge.net иначе и трудно себе представить процесс со всеми вытекающими проблемами конфигурированияи и сборки версий.
Не согласен. На sourceforge.net CVS - позволяет работать и так и этак. А вот у VSS - проблемы с этим.
При корпоративной разработке, на которую ориентрован VSS,
Куда он ориентирован????? Боже, помилуй...
- Насколько объемен ваш проект в VSS?
- Сколько лет ведется разработка?
- Сколько раз падала база?
- Были ли потери из-за отсутсвия Back-UP.
- Как часто ваш администратор бэкапит БД VSS.
- Сколько человек в команде?
- Сколько направлений (подверсий) у Вашего проекта?
Вася Петю не ждет, потому что Вася и Петя при нормальной организации работ и модульной декомпозиции не должны править один и тот же файл.
Не факт. Видать мелковат ваш проект. У нас такая проблема может стоять.
А если Вася дожен подменить Петю, то для всех разработчиков существует административное правило - постоянный check in своего творчества в конце рабочего дня. Это такой же простой прием, как и единообразная среда на каждом рабочем месте вплоть до совпадения абсолютных путей расположения файлов. Все эти меры позволяют экономить время на разборках между Петями, Васями и тем менеджером по конфигурации, который должен их "разводить".
Не должен их никто "разводить". Каждый участник может сам принять решение, что сделать со своими изменениями. "Разводка" - это дополнительные рамки к тем, о которых Вы выше написали. :)
РЕЗЮМИРУЮ:
ВСЕ ТО, ЧТО ВЫ ОПИСАЛИ - ПРОДИКТОВАНО VSS. Нормальная система не накладывает ограничений на разработку. Она позволяет выбрать оптимальный вариант, приемлемый для конкретного случая. И с этим трудно не согласится. VSS - это не то средство, которое я могу советовать автору топика. Часть ограничений возникает из за отсутсвия поддержки Branch (Повторяюсь). Циатата от Ника: "... When the release is done, changes on the frozen branch can be merged back into the main branch.) SourceSafe"s branching support fails to effectively support any of this".
| № 57 23-04-2003 12:56 | |
Ответ на »сообщение 56« (Andrew Semack)
___________________________
Да, инструмент куплен, не VS, а MSDN-подписка, но это к теме не относится.
То что вы описали - пример классического "бардака" :) Подумайте, зачем тогда вообще нужна VCS, если каждый разработчик работает в своей ветке ? :)
"Сплошь и рядом" другая схема - разработка идет в одной ветке. Над основной версией. Бранч нужен совершенно для определенных целей, например, для выпуска хотфиксов или проверки возможности использования новых модулей перед введением их в основную продакшн-версию.
Технических проблем с блокировками не существует - в VSS есть такой флажок в настройках - allow multiple checkouts, вы его, видимо, не заметили.
При этом никто не отменяет проблем, возникающих при использовании такой системы блокировок в ЛЮБОЙ системе, а именно необходимости постоянно разрешать конфликты - самый неприятный источник ошибок и потерь.
Поэтому использовать данный режим разработки следует только в случаях, когда это действительно требуется. Скажем, при разработке на sourceforge.net иначе и трудно себе представить процесс со всеми вытекающими проблемами конфигурированияи и сборки версий.
При корпоративной разработке, на которую ориентрован VSS, Вася Петю не ждет, потому что Вася и Петя при нормальной организации работ и модульной декомпозиции не должны править один и тот же файл. А если Вася дожен подменить Петю, то для всех разработчиков существует административное правило - постоянный check in своего творчества в конце рабочего дня. Это такой же простой прием, как и единообразная среда на каждом рабочем месте вплоть до совпадения абсолютных путей расположения файлов. Все эти меры позволяют экономить время на разборках между Петями, Васями и тем менеджером по конфигурации, который должен их "разводить".
| № 56 23-04-2003 12:02 | |
Ответ на »сообщение 55« (Сергей Тарасов)
___________________________
Вопрос был, поддерживаются ли бранчи в VSS. Выяснилось, что поддерживается, причем в явном виде.
Явный вид, это в CVS например, когда ты можешь запросить дерево. VSS?
Насчет убогости или продвинутости - это отдельная тема. Нам вполне хватает, а для выяснения "кто лучше" необходимо выдвигать четкие критерии и по ним сравнивать, а не заниматься трепом "у этой бранча нет, а та - дорогая и навороченная".
Человек спросил в топике, я ему ответил. ИМХО попахивает ревностной любовью к VSS. Это Ваше право. Я проанализировал не одну систему, поскольку пришлось заниматься Athlant'ом - и делаю выводы. А насчет платности, тоже вопрос. Неужели VS Studio куплен? Хотя многих это сейчас не волнует. :(
Share позволяет работать только с нужными файлами ветки в режиме brahch (а не со всеми - это еще надо специально придумать такой случай, чтобы понадобилось все файлы в проекте бранчить), а затем их сливать, пользуясь визуальной тулзой - компаратором.
:))))) Сергей, классический пример (Я думаю, Вы не будете возражать):
Допустим есть проект. В нем участвуют 5 разработчиков. Каждый разработчик создает себе ветку от основной и в ней работает, чтоб не создавать блокировок. После изменений сливает в основной ствол и решает конфликты. Пожалйся предложите схему в VSS? А схема такая сплошь и рядом.
Еще. А как Вы решаете проблемы с блокировками в VSS? Вася ждет пока Петя закончит редактировать нужный Васе файл? И сколько длится это ожидание? Резервирование VSS также не поддерживает, насколько я знаю, чтоб решить проблему с блокировками.
Еще раз: Share предназанчен для создания SymLink файлам в различных папках\проектах, чтобы не создавать этим файлам дупов в хранилище.
Упомянутый не к ночи CVS не менее убог. Особенно раздражет невозможность удалять директории, созданные по ошибке. Но дареному коню в зубы не смотрят.
Это несущественный недостаток. Достаточно залезть в репозиторий, а Вы занете что он представлен в виде каталогов с фалами на файловой системе, и удалить ненужные каталоги.
| № 55 23-04-2003 01:18 | |
Ответ на »сообщение 54« (Andrew Semack)
___________________________
Вопрос был, поддерживаются ли бранчи в VSS. Выяснилось, что поддерживается, причем в явном виде.
Насчет убогости или продвинутости - это отдельная тема. Нам вполне хватает, а для выяснения "кто лучше" необходимо выдвигать четкие критерии и по ним сравнивать, а не заниматься трепом "у этой бранча нет, а та - дорогая и навороченная".
Share позволяет работать только с нужными файлами ветки в режиме brahch (а не со всеми - это еще надо специально придумать такой случай, чтобы понадобилось все файлы в проекте бранчить), а затем их сливать, пользуясь визуальной тулзой - компаратором.
Упомянутый не к ночи CVS не менее убог. Особенно раздражет невозможность удалять директории, созданные по ошибке. Но дареному коню в зубы не смотрят.
| № 54 23-04-2003 00:58 | |
Ответ на »сообщение 51« (Сергей Тарасов)
___________________________
Это не так. Ветку (проект) отвести возможно, так же как и возможно потом эту ветку влить обратно в основной проект с учетом сделанных изменений. Делается это все достаточно просто через интерфейс.
Подробнее см. операции share, branch и merge.
Какое отношение к Branch'ам имеет Share? :) Это обычный SymLink
Достаточно сравнить брэнчи ClearCase или CVS и сделать вывод, что то, что есть в VSS - означает, что их нет. :) Я хотел бы посмотреть на того, кто реально использует ветки в VSS: ведут разработку в разных ветках, а потом сливают в одну. А та убогость на Label и Merge - лучше не надо о этом - я видел... :(
| № 53 22-04-2003 18:19 | |
Ответ на »сообщение 52« (Dimentiy)
___________________________
Ник, у тебя в "Закладках" про Subversion написано - "Java".
Какая джава? При чём джава? :-))
Ах я тварь! Исправил. Просто у тигриса многое остальное на жабе
| № 52 22-04-2003 18:12 | |
Ник, у тебя в "Закладках" про Subversion написано - "Java".
Какая джава? При чём джава? :-))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
