Комментарии 74
Впереди еще внедрение непрерывной разработки и автоматической сборки проектов. Удачи с этим. И, надеюсь, вам все-таки удастся просмотреть статьи на тему «10 вещей, которые надо (не надо) делать при работе с...» — а то как-то слижком уж много граблей было у вас на пути.
Вердикт: Если используется подход один проект — одно хранилище, то папки trunk, tags, branches лучше размещать только в корне хранилища.
Разработчики VisualSVN, например, советуют заводить всего один репозиторий, а в нем создавать отдельные папки проектов.
Это, я думаю, исключительно потому, что у проектов, разрабатываемых одной командой рано или поздно появится общий код — какие-то базовые модули, общие классы и их захочется вынести в «общак». В рамках одного репозитория между ветками — легко. Организовывать как-то синхронное хранилище в нескольких репозиториях — муторно.
С другой стороны, если общего кода гарантировано нет (разработка под разные платформы или кардинально разных проектов разными людьми), лучше все же разные репозитории.
С другой стороны, если общего кода гарантировано нет (разработка под разные платформы или кардинально разных проектов разными людьми), лучше все же разные репозитории.
Обычно, хочется всё сразу спроектировать и решить что будет отдельной библиотекой, а что войдет в общий код. На деле так не получается. Зачастую, то что выделяется в отдельную либу больше нигде в итоге не используется. Однако в процессе разработки может действительно родиться нечто обобщенное и полезное для использования в других разработках, как раз тогда когда весь код уже будет в репозитарии проекта.
Нам не хотелось иметь сквозную нумерацию ревизий для всех проектов.
У вас все в интранете, без внешних адресов и VPN? Просто как-то странно, что программист, выбывший на 3 месяца, не коммитил код в общий репозиторий. Или коммитил, но без него не было понятно, что к чему?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По собственному опыту могу сказать, что mercurial или git намного удобнее при единоличной работе: не нужно подымать сервер; работа по разворачиванию новых изменений на production-машине — дело одного обновления из рабочего репозитория, в котором все уже оттестировано.
Я работаю с WAMP, разработка также ведется на Windows и мне очень импонирует расширение для Проводника, TortoiseHg, которая является аналогом TortoiseSVN.
Как мне кажется, в малой команде также будет удобнее использовать без-сервеные решения. Для организации модели разработки с центральным хранилищем (можно и без него, просто считать, что у тим-лида — Самое Главное Хранилище) в том же Mercurial предусмотрен режим работы «web-server» — встроенное решение, при котором подымается процесс-демон, работащий по http(s).
Я работаю с WAMP, разработка также ведется на Windows и мне очень импонирует расширение для Проводника, TortoiseHg, которая является аналогом TortoiseSVN.
Как мне кажется, в малой команде также будет удобнее использовать без-сервеные решения. Для организации модели разработки с центральным хранилищем (можно и без него, просто считать, что у тим-лида — Самое Главное Хранилище) в том же Mercurial предусмотрен режим работы «web-server» — встроенное решение, при котором подымается процесс-демон, работащий по http(s).
Что-то многовато проблем для одного проекта. Озвучьте хоть масштаб — сколько килострок кода в вашем проекте всего. Вроде как упоминается что команда маленькая.
Но в целом могу сказать: незачем было заводить кучу хранилищ. Привязываться к репозиторию по IP-адресу — тоже странное решение. Опять же при небольшом масштабе проекта можно было обойтись и без svn:externals.
Но в целом могу сказать: незачем было заводить кучу хранилищ. Привязываться к репозиторию по IP-адресу — тоже странное решение. Опять же при небольшом масштабе проекта можно было обойтись и без svn:externals.
Стандартно :) Когда только начинали работать с SVN тоже зачем-то возились с svn:externals. Хотелось делать всё «по уму». А на деле это ненужные сложности. Одного хранилища для всего оказалось бы достаточно. Если даже какие-то родившиеся библиотеки потом понадобиться использовать где-то в другом проекте, то лучше их перетащить туда или именно тогда пользоваться external.
Что ни говори, а тот же Lock — в SVN, он «стопудовый». А это в распределённой работе над проектом очень важно и конфликтобезопасно :)
Что ни говори, а тот же Lock — в SVN, он «стопудовый». А это в распределённой работе над проектом очень важно и конфликтобезопасно :)
Мне вас жаль :(
В конце вы не сказали, что уходите с SVN. Почему?
В конце вы не сказали, что уходите с SVN. Почему?
Вам бы очень помогло использование DVCS (Mercurial,Git). Чем раньше перейдете на распределенные тем лучше. С SVN легче всего перейти на Mercurial. Тем более если разработка на Windows — с Mercurial будет меньше мучений.
SVN во всем этом вообще ни причем. Использовав DVCS — сценарий был бы точно таким же. Проблемы были в знаниях и опыте участников проекта, в неправильной организации разработки, но никак не в используемых инструментах.
Проблемы в инструменте контроля версий все-таки есть. Они составляют небольшой процент от всех остальных проблем, НО мне кажется от этих проблем можно избавиться сменив систему контроля версий на распределенную.
Очень рекомендую!
Очень рекомендую!
Много раз читал, что SVCS — это хорошо, даже доводы приводились. Но как-то они не особо существенны по сравнению с svn. У меня стоит svn-сервер, на сервере WebSVN для просмотра изменений и прочего. И я, в общем-то, доволен.
В чем основная выгода-то?
В чем основная выгода-то?
Для такого проекта выгода была бы в легком объединении веток.
Я последний год работаю с Memorial и очень доволен. Обратно на svn не тянет.
Главным преимуществом считаю легкое ветвление и слияние веток.
Я последний год работаю с Memorial и очень доволен. Обратно на svn не тянет.
Главным преимуществом считаю легкое ветвление и слияние веток.
Коллега, а не поделитесь ли конкретными примерами, где используется частое легкое ветвление и слияние?
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Если такое положение вещей устраивает, то svn Вам вполне подходит.
У нас на каждую фичу отдельная ветка, которая потом сливается в ветку stable.
Таким образом можно легко отслеживать добавленные фичи, можно работать над несколькими фичами и фиксами одновременно, причем все они в разных ветках, а значит изолированны друг от друга.
У нас на каждую фичу отдельная ветка, которая потом сливается в ветку stable.
Таким образом можно легко отслеживать добавленные фичи, можно работать над несколькими фичами и фиксами одновременно, причем все они в разных ветках, а значит изолированны друг от друга.
Вот смысл делать ветку на каждую фичу мне не очень понятен.
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
>Но зачем их каждый раз-то принудительно делать?
Так проще потом отслеживать фиксы и фичи.
Еще вам кажется это странным, потому что в svn время на это действие зависит от размера репоза, т.к. надо переключиться. В Mercurial это ни отчего не зависит и переключаться почти не надо. нужно обновиться до stable и пометить рабочую копию названием новой ветки. Тут это гораздо проще.
Я тоже не понимал как и зачем, пока сам не попробовал. Сначала использовал hg как и svn раньше, но как только понял, что ветка в hg это не ветка в svn… Каааааак начал ветвить на каждый чих. Мне проще работать с ветками, тем более никогда не знаешь, когда придется отложить работу над веткой — завтра, или через 5 минут.
>Что конкретно имеется ввиду под «отслеживанием»?
Ничего такого. У меня это проще чем у вас. Есть задача сделать доставки. назвываем ветку delivery и поехали… потом мержим в stable. Через месяц надо сделать что-то еще по доставкам. Обновляемся на delivery. Мержим последние изменения из stable и снова работаем по доставкам. В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
>Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Я тоже так раньше думал. Надо пробовать. Просто начните какой-нибудь проектик под DVCS и поиграйтесь с ветками.
Головной боли по интегрированию нет. Все сливается очень просто. Если вы в svn ответвили от ветки ответвленной когда-то от ветки (каламбур но специально), а теперь пытаетесь промержить все это в trunk — будет толпа конфликтов, при чем там, где их не должно быть, код то менялся последовательно. В DVCS все это сольется во едино без конфликтов.
Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
Так проще потом отслеживать фиксы и фичи.
Еще вам кажется это странным, потому что в svn время на это действие зависит от размера репоза, т.к. надо переключиться. В Mercurial это ни отчего не зависит и переключаться почти не надо. нужно обновиться до stable и пометить рабочую копию названием новой ветки. Тут это гораздо проще.
Я тоже не понимал как и зачем, пока сам не попробовал. Сначала использовал hg как и svn раньше, но как только понял, что ветка в hg это не ветка в svn… Каааааак начал ветвить на каждый чих. Мне проще работать с ветками, тем более никогда не знаешь, когда придется отложить работу над веткой — завтра, или через 5 минут.
>Что конкретно имеется ввиду под «отслеживанием»?
Ничего такого. У меня это проще чем у вас. Есть задача сделать доставки. назвываем ветку delivery и поехали… потом мержим в stable. Через месяц надо сделать что-то еще по доставкам. Обновляемся на delivery. Мержим последние изменения из stable и снова работаем по доставкам. В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
>Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Я тоже так раньше думал. Надо пробовать. Просто начните какой-нибудь проектик под DVCS и поиграйтесь с ветками.
Головной боли по интегрированию нет. Все сливается очень просто. Если вы в svn ответвили от ветки ответвленной когда-то от ветки (каламбур но специально), а теперь пытаетесь промержить все это в trunk — будет толпа конфликтов, при чем там, где их не должно быть, код то менялся последовательно. В DVCS все это сольется во едино без конфликтов.
Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
> Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
Да все так, просто разный подход.
Реальный пример недельной давности.
Три ветки:
— текущая версия в эксплуатации (PROD)
— версия в тестировании (RC)
— основная разработка (HEAD)
В PROD-версии несколькими коммитами правятся баги и двумя коммитами мержатся в RC. При попытке за раз смержить в HEAD оба мержа PROD->RC получаем конфликт на свойстве svn:merginfo.
При непоследовательном слиянии, например, после бекпорта RC->PROD при слиянии PROD -> RC надо либо пропустить ревизию с бекпортом либо только зарегистрировать слияние. Ситуация усложняется было изменение дерева, tree conflict гарантирован.
Три ветки:
— текущая версия в эксплуатации (PROD)
— версия в тестировании (RC)
— основная разработка (HEAD)
В PROD-версии несколькими коммитами правятся баги и двумя коммитами мержатся в RC. При попытке за раз смержить в HEAD оба мержа PROD->RC получаем конфликт на свойстве svn:merginfo.
При непоследовательном слиянии, например, после бекпорта RC->PROD при слиянии PROD -> RC надо либо пропустить ревизию с бекпортом либо только зарегистрировать слияние. Ситуация усложняется было изменение дерева, tree conflict гарантирован.
С точки зрения всего проекта — если закрыть глаза на ветвление — у DVCS гораздо лучше организована работа с репозиторием, что и будет главным плюсом.
Я с вами согласен!
У вас не с svn проблемы, а с организацией процесса разработки. В частности, вот эти пункты:
Причём большая часть проблем — явные косяки вашего руководства и системных администраторов.
- отсутствие выделенного сервера для vcs;
- доступ к компьютерам по ip а не именам;
- отсутствие системы continous integration, чтобы проект собирался и тестировался в автоматическом режиме;
- отсутствие у больного сотрудника доступа к рабочей сети из дома.
Причём большая часть проблем — явные косяки вашего руководства и системных администраторов.
Вероятно, статья software-testing.ru/library/testing/general-testing/81 может быть полезна вам
не поделитесь как-нибудь впечатлениями о разработке в Qt в сравнении с Дельфи?
Просто рай! Я в свободное время участвую еще в одном проекте на java. Могу сказать что Delphi по языковой и компонентной частям очень сильно отстал от всего мира. Чего стоит постоянное допиливание компонентов под свои нужды. Хотя и на них до сих пор поддерживаются и дорабатываются сложнейшие старые разработки.
Не пробовали пользоваться cmake для сборки проекта?
С qt оно дружит неплохо, да и с путями должно помочь разобраться.
С qt оно дружит неплохо, да и с путями должно помочь разобраться.
Не очень понял как у вас все было устроено. Попробую рассказать свою ситуацию. Она у меня вобщем-то сходная: разработка на QT, проект большой (с включением модулей и внешних библиотек), управление проектом на SVN в связке с Trac, автодокументирование на Doxygen. Для репозитария и Trac — выделенный сервер с DNS записью в корпоративной сети.
Организовывал вроде по классике…
Репозитарий с папками trunk (основная стабильная ветвь), branches (ветки в основном для внедрения нового функционала и отладки), tags ( некоторые «вехи» проекта, по сути milestone из Trac'а).
Файловая структура самого проекта
/
— bin/ — папка куда собираются бинарники
— lib/ — для компилируемых библиотек
— doc/ — документация
— obj/ — для промежуточных файлов компиляции ( /module/[release|debug] )
— inc/ — «общие» инклюды от отдельных модулей
— src/ — исходники проекта (внутри папки — по каждому модулю программы)
Есть общий *.pri файл, который необходимо подключать ко всем pro модулей проекта. Содержит установки, организующие использование файловой структуры проекта.
Основной pro файл проекта содержит всего несколько строк:
Все пути — относительные (не очень понял откуда у автора взялся trunk в путях...).
Корпоративная сеть также недоступна извне. Для работы дома и в командировках используется git, работающий через git-svn (позволяет связывать общий репозитарий svn и временные git с возможностью коммита и чекаута туда-обратно).
Есть инструкция разработчика, в которой все описано (работа с проектом, основные принципы оформления кода, именования переменных и функций). Она «настоятельно рекомендована» всем работающим с проектом.
Ну вобщем как-то так… Шишек пока не набили, проблем особых не было (ну разве что при подключении нового разработчика нужно убедить его работать по общим правилам, что не всегда проходит гладко :-) ).
Организовывал вроде по классике…
Репозитарий с папками trunk (основная стабильная ветвь), branches (ветки в основном для внедрения нового функционала и отладки), tags ( некоторые «вехи» проекта, по сути milestone из Trac'а).
Файловая структура самого проекта
/
— bin/ — папка куда собираются бинарники
— lib/ — для компилируемых библиотек
— doc/ — документация
— obj/ — для промежуточных файлов компиляции ( /module/[release|debug] )
— inc/ — «общие» инклюды от отдельных модулей
— src/ — исходники проекта (внутри папки — по каждому модулю программы)
Есть общий *.pri файл, который необходимо подключать ко всем pro модулей проекта. Содержит установки, организующие использование файловой структуры проекта.
Основной pro файл проекта содержит всего несколько строк:
CONFIG += ordered
TEMPLATE = subdirs
SUBDIRS = (перечисление подпапок с модулями)
Все пути — относительные (не очень понял откуда у автора взялся trunk в путях...).
Корпоративная сеть также недоступна извне. Для работы дома и в командировках используется git, работающий через git-svn (позволяет связывать общий репозитарий svn и временные git с возможностью коммита и чекаута туда-обратно).
Есть инструкция разработчика, в которой все описано (работа с проектом, основные принципы оформления кода, именования переменных и функций). Она «настоятельно рекомендована» всем работающим с проектом.
Ну вобщем как-то так… Шишек пока не набили, проблем особых не было (ну разве что при подключении нового разработчика нужно убедить его работать по общим правилам, что не всегда проходит гладко :-) ).
Мы намучались с SVN вдоволь. У нас несколько команд и куча проектов. Сначало все работали с одной веткой. Было неудобно, но в целом терпимо. Решили, что каждая команда будет работать в своей ветке, а потом по окончанию итерации сливать в главную ветку. В итоге, в конце итерации устраилвся многочасовой merge-fest с разруливанием многочисленных конфликтов и так каждую итерацию. Это жутко надоело. Выделили пару человек, которые полностью подготовили GIT репозиторий и просто в один день все встали и пересели на GIT. Все довольны =)
Вообще SVN предполагает использовать ветки для внедрения нового функционала, тестирования и т.п. Т.е. то, что пока нельзя назвать стабильным и отлаженным. Когда код новой фичи разработан, отлажен и проверен, то его можно слить с trunk'ом. Основная ветвь — это собственно стабильная и отлаженная последняя версия кода, которая готова к продакшену.
Не очень понял как git позволил вам избавится от конфликтов. В любой vcs правка одной и той же строчки кода разными разработчиками — конфликт. Git, по-моему, как раз более подвержен конфликтам т.к. не имеет даже системы блокировок (lock) файлов.
Не очень понял как git позволил вам избавится от конфликтов. В любой vcs правка одной и той же строчки кода разными разработчиками — конфликт. Git, по-моему, как раз более подвержен конфликтам т.к. не имеет даже системы блокировок (lock) файлов.
дело как-раз в том, что конфликты порой на пустом месте в SVN возникали. Файл никто не редактировал, но он вызывает конфликт. Конфликт разрулен, файл всю итерацию никто не редактирует, а при мердже снова конфликт. В общем надоело. С гитом много проще все. Конфликты бывают но очень редко и очень быстро правятся. Плюс куча других плюшек :)
Я кажется понял о чем речь. SVN очень не любит когда меняется файловая структура (копирование/удаление файлов и папок) в разных ветках.
Да, действительно сталкиваюсь с этим. Просто приходится быть «по-строже» с файловой структурой.
Да, действительно сталкиваюсь с этим. Просто приходится быть «по-строже» с файловой структурой.
Судя по всему merge в git реализован гораздо лучше, чем в svn.
Не поделитесь конкретными примерами? Типа вот такой сценарий, в svn все было бы плохо, а в git — все хорошо.
Не поделитесь конкретными примерами? Типа вот такой сценарий, в svn все было бы плохо, а в git — все хорошо.
с ходу сложно вспомнить так конкретные примеры. Один из, я уже назвал чуть выше. Плюс регулярные потери файлов при больших мерджах, плюс конфликты на «пустом месте», когда одна команда работает над своим кодом, другая над другим. И когда одна коммитит код, а вторая просто подтягивает ихний код и тут возникают конфликты. Вот это убивало просто. К тому же невозможность быстрого создания и удаления веток (жуткий гимор был), невозможность нормального грепа по коду из-за .svn хлама. Много сложностей было. Возможно это всё организационное было, но с гитом как-то много спокойней стало :)
Git рулит!
Хорошая статья как наставление для начинающих. Она замечательно говорит о том, что прежде чем начать использовать ту или иную CVS, надо ознакомиться с документацией, посмотреть/почитать как эта CVS интегрируется с вашей IDE, какие есть рекомендации.
Грустно конечно, что начальство не понимает всю важность наличия централизованного сервера CVS с бэкапами. Жаль, что это у нас встречается достаточно часто, и приходится своими силами как-то выкручиваться.
Грустно конечно, что начальство не понимает всю важность наличия централизованного сервера CVS с бэкапами. Жаль, что это у нас встречается достаточно часто, и приходится своими силами как-то выкручиваться.
Ну помоему IDE здесь совсем не причем.
С eclipse и netbeans mercurial нормально интегрируется, однако мне кажется, что из коммандной строки работать гораздо быстрее и удобнее. Единственное для чего нужен GUI — это мержи и диффы, но тут не обязательно использовать IDE — можно в любом GUI клиенте это делать.
С eclipse и netbeans mercurial нормально интегрируется, однако мне кажется, что из коммандной строки работать гораздо быстрее и удобнее. Единственное для чего нужен GUI — это мержи и диффы, но тут не обязательно использовать IDE — можно в любом GUI клиенте это делать.
IDE в данном случае очень даже причем, потому что народ работает из под винды, после Дельфей, и обычно такие программисты мало что знают про cmd, и они все привыкли к гуям, встроенным в их любимую IDE. Помню просто с каким мы скрипом переводили своих win-программистов с VS на использование SVN — это была мука.
И наличие черепахи SVN их не устраивало, про cmd я вообще молчу.
P.S. Я с вами полностью согласен, ибо сам использую шелл, и считаю его самым быстрым и удобным способом работы, но как показывает опыт, для многих вин-программистов это не вариант.
И наличие черепахи SVN их не устраивало, про cmd я вообще молчу.
P.S. Я с вами полностью согласен, ибо сам использую шелл, и считаю его самым быстрым и удобным способом работы, но как показывает опыт, для многих вин-программистов это не вариант.
Может быть я не многие вин-программисты (потому видимо и оказался под *nix), но даже в старые добрые времена, пописывая на php под WinXP использовал cvs и svn ТОЛЬКО из cmd.exe, ибо черепаха мне показалась куда менее понятной чем cvs commit и cvs status и cvs update (а других комманд я тогда еще не знал)
НЛО прилетело и опубликовало эту надпись здесь
Вердикт: Крайне важно поддерживать принцип: слил из хранилища и собрал без проблем.
Наверное это зависит от специфики проекта, но я думаю, что все же лучше собирать на отдельном сервере (а потом запускать то что собралось на другом отдельном сервере). Иначе возрастает риск столкнуться с проблемами типа: "… а на моем ПК это работат".
а че ваш программист из дома не мог коммитить?
Как то совсем печально смотрится заголовок «в сложном проекте», если у вас такие банальные вещи вызывают трудности. Мой совет — уходите из этого места куда-нибудь, где вы получите реальный опыт в действительно сложных проектах. Если возьмут конечно.
Если Вы считаете, что научились программировать изучив СКВ — Вы сильно ошибаетесь. Использование СКВ не гарантирует сложность проекта, как и обратное. Я знаю проекты, которые разрабатывались без использования СКВ начиная с 90-х годов. Они до сих пор прекрасно развиваются и работают.
Зато неиспользование СКВ гарантирует сложность почти любого проэкта где работает больше 1 человека и количество сущностей переваливает за 100. Я могу понять неиспользование таких средств в 80-х, где инструментария было мало и стоил он заоблачно, но в теж же 90-х уже существовал CVS, а чейчас количество качественніх и безплатніх инструментов перевалило за 10. Если вы любите создавать себе трудностина ровном месте и там где они в принципе не должны возникать, пожалуйста работайте без СКВ.
Исспользование СКВ это мимнимальная гигиена, без этого здача каждого этапа более-менее большого проэкта превращается в подвиг.
Ну а ручная зборка с разными настройкаим компонент это вообще феерическая неорганизованность и проблема не в СКВ, а в отсутствии минимального менеджмента.
Исспользование СКВ это мимнимальная гигиена, без этого здача каждого этапа более-менее большого проэкта превращается в подвиг.
Ну а ручная зборка с разными настройкаим компонент это вообще феерическая неорганизованность и проблема не в СКВ, а в отсутствии минимального менеджмента.
Специально для тех, у кого возникли вопросы по поводу сложности проекта, приведу небольшую статистику:
Metric Value
Total Files 1685
Total Lines 119776
Avg Line Length 30
Code Lines 71747
Comment Lines 29009
Whitespace Lines 20514
Code/(Comment+Whitespace) Ratio 1,45
Code/Comment Ratio 2,47
Code/Whitespace Ratio 3,50
Code/Total Lines Ratio 0,60
Code Lines Per File 42
Comment Lines Per File 17
Whitespace Lines Per File 12
Статистика получена с помощью программы Code Analyzer. В код не включены тесты и прошивки контроллеров.
В этом проекте организована голосовая связь между операторами, подключено 16 устройств в железе, реализована математика стрельбы артиллерии и радиолокации. В двух приложениях более 50 окон. В двух приложениях осуществляется работа с картой (перемещение объектов, работа с ними. Отображение обстановки). Организовано единое время моделирования и работы. Выполняется удаленное управление рабочими местами и ведется сбор статистики работы устройств и операторов. Организовано взаимодействие с двумя различными программными комплексами сторонних разработчиков.
На других предприятиях я не работал, аудитов у нас не проводится, поэтому судить о сложности проектов могу только субъективно. Каково ваше мнение?
Metric Value
Total Files 1685
Total Lines 119776
Avg Line Length 30
Code Lines 71747
Comment Lines 29009
Whitespace Lines 20514
Code/(Comment+Whitespace) Ratio 1,45
Code/Comment Ratio 2,47
Code/Whitespace Ratio 3,50
Code/Total Lines Ratio 0,60
Code Lines Per File 42
Comment Lines Per File 17
Whitespace Lines Per File 12
Статистика получена с помощью программы Code Analyzer. В код не включены тесты и прошивки контроллеров.
В этом проекте организована голосовая связь между операторами, подключено 16 устройств в железе, реализована математика стрельбы артиллерии и радиолокации. В двух приложениях более 50 окон. В двух приложениях осуществляется работа с картой (перемещение объектов, работа с ними. Отображение обстановки). Организовано единое время моделирования и работы. Выполняется удаленное управление рабочими местами и ведется сбор статистики работы устройств и операторов. Организовано взаимодействие с двумя различными программными комплексами сторонних разработчиков.
На других предприятиях я не работал, аудитов у нас не проводится, поэтому судить о сложности проектов могу только субъективно. Каково ваше мнение?
Вы ошиблись, я не считаю что можно научиться программировать используя СКВ. Можно научиться работая\общаясь\изучая работы людей, которые выше тебя по уровню и учиться у них, и, судя по всему, у вас таких очень мало.
А проект похоже действительно сложный, но измерять нужно его не количеством строк кода, а решениями, которые были выбраны при разработке системы.
Но главное это конечно результат, если все работает, легко сопровождается и легко модифицируется под изменения в требованиях, то это конечно перевешивает все недостатки, которые были допущены на этапе разработки и систему действительно можно назвать успешной.
А проект похоже действительно сложный, но измерять нужно его не количеством строк кода, а решениями, которые были выбраны при разработке системы.
Но главное это конечно результат, если все работает, легко сопровождается и легко модифицируется под изменения в требованиях, то это конечно перевешивает все недостатки, которые были допущены на этапе разработки и систему действительно можно назвать успешной.
Боюсь все перечисленные проблемы вы бы получили с любой системой контроля версий. Вам и на чачальству срочно сесть за изучение дисциплины Software Configuration Management, ударение на Management, потому что проблемы в большинстве организационные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы использовали SVN в сложном проекте