Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
Если надо дополнить другими вариантами, пишите.
Ну хорошо - узнали, что среди голосовавших 50% используют svn. И что?
Ну как минимум - узнали, что треть голосовавших не пользуется, но хотело бы. А это повод написать статью, и может быть даже провести семинар :)
Мне будет проще сделать выбор при поиске :) потому как ставить надо, а с чего начать - хз.
Спасибо автору опроса.
Спасибо автору опроса.
а выбор систем контроля версий - настолько обширная тема?
имхо 1 дня для гугления вполне достаточно чтобы определиться с системой, для этого и хабра не надо
к тому же - этот опрос никакой смысловой нагрузки не несёт, разве что статистика...
имхо 1 дня для гугления вполне достаточно чтобы определиться с системой, для этого и хабра не надо
к тому же - этот опрос никакой смысловой нагрузки не несёт, разве что статистика...
А все равно приятно. Я смотрю вы не особо то пишете :) зато сколько критики.
не особо публикуюсь на хабре?
я просто не журналист и не переводчик
ps: ну а по правде - кроме "приятно" и "я теперь знаю что юзают хабровцы" ты из голосования что-нибудь почерпнул? только не лукавь!!! ;)
я просто не журналист и не переводчик
ps: ну а по правде - кроме "приятно" и "я теперь знаю что юзают хабровцы" ты из голосования что-нибудь почерпнул? только не лукавь!!! ;)
Ну вот я почерпнул (выше писал) - мне интересно, какие темы интересует людей в отрасли web-разработки. За что автору опроса спасибо.
Да. Мне особо не охота разбираться что ставить, а ставить надо. А большинство подскажет оптимальное решение, и я не запариваясь его использую.
Я тоже не журналист и не переводчик, именно поэтому то, что нравится - плюсую, а то что не нравится оставляю без внимания.
Я тоже не журналист и не переводчик, именно поэтому то, что нравится - плюсую, а то что не нравится оставляю без внимания.
об оптимальности можно говорить только тогда, когда определён критерий, относительно которого можно сравнивать варианты
ты критерии не озвучил => об оптимальности говорить нет смысла ;)
большинство - может лишь сказать то, что юзают они. для того же, чтобы узнать, что лучше в твоей конкретной ситуации, нужно знать эту ситуацию
ты критерии не озвучил => об оптимальности говорить нет смысла ;)
большинство - может лишь сказать то, что юзают они. для того же, чтобы узнать, что лучше в твоей конкретной ситуации, нужно знать эту ситуацию
Добавьте минусов, пионэры. А то дяденьки вам не расскажут, зачем СКВ нужна.
Microsoft Source Safe
не используем и не планируем.
какой бардак!
какой бардак!
Для тех, что не пользуется SVN, но хочет попробовать: книга Управление версиями в Subversion.
А может кто-то вкратце рассказать что это и зачем? Много слышу, а с чего начать и какая практическая польза?
например, такая - для тех, что системами контроля версий не пользовался, при приеме на работу мы предлагаем зарплату на 20% меньше
Могу. Если кратко, то польза такая:
1. Сохраняется история изменений файлов (это полезно даже если "над проектом работает только один человек"). Это как бы бесконечное undo на каждый файл, с возможностью смотреть и сравнивать любые прошлые версии.
2. Если разработчиков несколько - видно, кто, когда и где менял тот или иной файл. Т.е. про каждую строчку кода в любом файле можно сказать, кем и когда она была написана или отредактирована.
3. Наконец, система контроля версий сама сливает правки, внесенные разными разработчиками. Т.е. двое могут одновременно править "один и тот же" файл, без опасности затереть изменения друг друга. После правки система или сама сольет изменения, или (если сама не сможет) - покажет кто что исправил и предложит разобраться человеку.
1. Сохраняется история изменений файлов (это полезно даже если "над проектом работает только один человек"). Это как бы бесконечное undo на каждый файл, с возможностью смотреть и сравнивать любые прошлые версии.
2. Если разработчиков несколько - видно, кто, когда и где менял тот или иной файл. Т.е. про каждую строчку кода в любом файле можно сказать, кем и когда она была написана или отредактирована.
3. Наконец, система контроля версий сама сливает правки, внесенные разными разработчиками. Т.е. двое могут одновременно править "один и тот же" файл, без опасности затереть изменения друг друга. После правки система или сама сольет изменения, или (если сама не сможет) - покажет кто что исправил и предложит разобраться человеку.
На работе --- SVN (раньше был ужасный до невозможности SourceSafe). Дома --- git (всем рекомендую!). А почитать можно, как всегда, на википедии. (Хотя, честно говоря, не верится, что кто-то пишет программы без SCM системы).
Почему-то "на википедии" в комментарии не сделалось ссылкой... Вот она: http://en.wikipedia.org/wiki/Revision_co…
Нескромный вопрос: почему дома -git?
Причин несколько:
1) Это распределенная система, как следствие --- для создания нового репозитория нужно сделать git init (и все!).
2) Она безо всяких проблем и сразу поняла русский язык в коммитах. С SVN у меня были проблемы.
3) Очень просто и естественно работают ветки. Для разработки в одиночку это главная killer-фича git.
4) Fast as f*ck.
1) Это распределенная система, как следствие --- для создания нового репозитория нужно сделать git init (и все!).
2) Она безо всяких проблем и сразу поняла русский язык в коммитах. С SVN у меня были проблемы.
3) Очень просто и естественно работают ветки. Для разработки в одиночку это главная killer-фича git.
4) Fast as f*ck.
Спасибо.
1) Это распределенная система, как следствие --- для создания нового репозитория нужно сделать git init (и все!)
Не вижу связи распределенности со скоростью создания репозитария. В svn вот достаточно сделать svnadmin create, а в cvs - cvs -d DIR init
Не надо лукавить! (Хотя, возможно, вы меня не так поняли). _Все_, что мне надо сделать, чтобы начать новый проект:
1) mkdir new_project
2) cd new_project
3) git init-db (у меня git 1.4, в 1.5 просто init называется)
В случае с SVN шаг 3 куда больше будет! Сначала надо придумать, где хранить репозиторий (+ mkdir + cd), затем svnadmin create (+ параметры), затем checkout (после cd в new_project), причем я только с 3 раза угадывал, как надо зашифровать локальный путь. Да, когда создаешь мега-проект --- это все равно. Но git позволяет использовать SCM для всего, что хочешь, не задумываясь над "администрированием". Для меня это --- плюс.
1) mkdir new_project
2) cd new_project
3) git init-db (у меня git 1.4, в 1.5 просто init называется)
В случае с SVN шаг 3 куда больше будет! Сначала надо придумать, где хранить репозиторий (+ mkdir + cd), затем svnadmin create (+ параметры), затем checkout (после cd в new_project), причем я только с 3 раза угадывал, как надо зашифровать локальный путь. Да, когда создаешь мега-проект --- это все равно. Но git позволяет использовать SCM для всего, что хочешь, не задумываясь над "администрированием". Для меня это --- плюс.
В случае с SVN шаг 3 куда больше будет! Сначала надо придумать, где хранить репозиторий (+ mkdir + cd), затем svnadmin create (+ параметры), затем checkout (после cd в new_project), причем я только с 3 раза угадывал, как надо зашифровать локальный путь.
Есть мнение, что вы не доконца прочли документ по осовам работы с svn, а (+ mkdir + cd) - это вообще не аргумент.
SVN рулит
Очень удобно работать в IDE с интеграцией с SVN. Даже когда в проект один человек
Очень удобно работать в IDE с интеграцией с SVN. Даже когда в проект один человек
Нет, над проектом работает только один человек
"Летели два крокодила, один зеленый, а другой — направо" (c)
Что за загадочная логика отражена во фразе "не используем систему контроля версий, поскольку над проектом работает один человек"? Одному человеку, выходит, не нужен инструмент для работы с версиямм?
На данный момент проголосовали почти 10%.
Действительно, так бывает. Хоть и очень похоже на вариант «Не использую, потому что не знаю, что это такое».
Действительно, так бывает. Хоть и очень похоже на вариант «Не использую, потому что не знаю, что это такое».
По моему, это очень хороший вариант ответа (спасибо автору опроса)! Он наглядно показывает, что многие не пользуются СКВ просто потому, что не понимают ее преимуществ.
Посколько понятие "Разработка ПО" имхо включает множество дисциплин, то упомяну, что для текстов бизнес-моделей и требований к ПО мы используем систему контроля версий MediaWiki.
Кстати, а как baseline'ы делаете?
+1, Вики это конечно хорошо, но ведение лога изменений с возможностью отката - это не единственная функция, которая от контроля версий требуется.
Если вопрос про получение документа, подлежащего согласованию - то пока проектов было мало - ручной проход, к/п в Ворд и сборка с оформлением также. Смотрим пока плагины для генерации PDF и проч.
Я исключительно про работу в рамках wiki. Предположим, сформулировано и занасено в wiki требование X. Страница имеет версию 1.0. Разработчики активно ее используют.
Далее возникает необходимость уточнить требование. 3-4 человека по очереди вносят правки в течении 2 дней, порождая версии 1.1 - 1.20. При этом версии 1.1-1.19 — определенно неконсистентны и остальным разработчикам руководствоваться ими нельзя.
Если программист Вася открыл страницу X и видит текущую версию — пусть это будет 1.6 — то как ему узнать, что он должен в истории открыть версию 1.0 и читать именно ее?
Далее возникает необходимость уточнить требование. 3-4 человека по очереди вносят правки в течении 2 дней, порождая версии 1.1 - 1.20. При этом версии 1.1-1.19 — определенно неконсистентны и остальным разработчикам руководствоваться ими нельзя.
Если программист Вася открыл страницу X и видит текущую версию — пусть это будет 1.6 — то как ему узнать, что он должен в истории открыть версию 1.0 и читать именно ее?
тут вы неявно предполагаете очень короткие циклы и вообще итерациность как норму жизни
у нас пока всё иначе
с требованиями в текущем режиме работают аналитики
по мере готовности аналитики выгружают baseline, на его основании формируется исходный набор задач
дальнейшие изменения требований накапливаются, а не идут сразу в работу. как только требования baseline более-менее реализованы (процентов на 80-90), накоплены новые требования и на их основе порождаются новый набор задач. циклы - от месяца до недели.
у нас пока всё иначе
с требованиями в текущем режиме работают аналитики
по мере готовности аналитики выгружают baseline, на его основании формируется исходный набор задач
дальнейшие изменения требований накапливаются, а не идут сразу в работу. как только требования baseline более-менее реализованы (процентов на 80-90), накоплены новые требования и на их основе порождаются новый набор задач. циклы - от месяца до недели.
В случае с длинными циклами и отсутствием итеративности я не вижу смысла использовать wiki.
А как ещё коллективно разрабатывать документацию и требования без привлечения специализированных инструментов? С пересылкой туда-сюда доковского файла? С извлечением его из SVN и правкой?
Wiki - это просто удобно.
Wiki - это просто удобно.
Wiki — удобно для документации. Согласен.
Но система контроля версий все-таки в разу удобнее непосредственно для кода.
Думаю, что все-таки необходимо совмещать и то и другое.
Но система контроля версий все-таки в разу удобнее непосредственно для кода.
Думаю, что все-таки необходимо совмещать и то и другое.
Абсолютно верно. Держать файлы в SVN.
Опробованная методика. В случае, когда у нас не только голый текст, а зоопарк из doc/xls/vss/mdl и т.п. это, согласно лично моей практике, заметно удобнее wiki.
Кстати вопрос: как вы организовали работу с картинками? Для меня это было в wiki большим геморроем именно в плане версионности и удобства добавления.
Опробованная методика. В случае, когда у нас не только голый текст, а зоопарк из doc/xls/vss/mdl и т.п. это, согласно лично моей практике, заметно удобнее wiki.
Кстати вопрос: как вы организовали работу с картинками? Для меня это было в wiki большим геморроем именно в плане версионности и удобства добавления.
Я к выявлению и фиксации требований заказчика и аналитиков подрядчика привлекаю. Хватит им мороки с wiki-синтаксисом, так вы предлагаете им ещё на каждый компьютер, откуда он будет работать, SVN-клиента ставить, обучать принципам check-in/check-out и т.д?
С картинками всё просто - они служат только для иллюстрации текста (если говорить о требованиях), и обновляются гораздо реже теста. Заказчик/эксперты картинки только смотрят и согласовывают/комментируют, но не правят.
Над инструментами совместного визуального рисования, что актуально, например, для моделей бизнес-процессов и UML, пока думаем. В сети есть только рисовалки и редакторы MindMap.
С картинками пока такой цикл - скопировать из среды моделирования в буфер, вставить в GIMP, оттуда сохранить и залить в MediaWiki через соответствующую кнопку. В нужно месте текста вставить или обновить ссылку на картинку.
С картинками всё просто - они служат только для иллюстрации текста (если говорить о требованиях), и обновляются гораздо реже теста. Заказчик/эксперты картинки только смотрят и согласовывают/комментируют, но не правят.
Над инструментами совместного визуального рисования, что актуально, например, для моделей бизнес-процессов и UML, пока думаем. В сети есть только рисовалки и редакторы MindMap.
С картинками пока такой цикл - скопировать из среды моделирования в буфер, вставить в GIMP, оттуда сохранить и залить в MediaWiki через соответствующую кнопку. В нужно месте текста вставить или обновить ссылку на картинку.
Я привык считать что у аналитиков (пусть — у большей части) достаточно интеллекта, чтобы освоить концепцию checkin/checkout. :)
По поводу картинок не совсем понял:
1. Какова судьба исходных файлов? Что делать, если нужно вернуться на три версии назад по тексту и картинкам и начать заново?
2. Каждый раз нужно придумывать новое имя файла для картинки?
По поводу картинок не совсем понял:
1. Какова судьба исходных файлов? Что делать, если нужно вернуться на три версии назад по тексту и картинкам и начать заново?
2. Каждый раз нужно придумывать новое имя файла для картинки?
Лучший способ сократить затраты на какую-либо операцию - это не делать её вовсе.
В MW есть версионность изображений, но я ей не пользовался.
В MW есть версионность изображений, но я ей не пользовался.
я пользовался версионированием картинок в медиавики
ну просто можно откатиться, так же как по тексту - посмотреть старые версии картинки.
новое имя придумывать не надо - там просто есть ссылка "загрузить новую версию этой же картинки".
то есть даже не надо править какие либо ссылки в тексте статьи, где эта картинка иллюстрирует что либо - новая версия автоматически подгружается там, поскольку по ссылке всегда последняя версия.
по-моему можно ставить и ссылки на старые версии картинки. то есть, к примеру, делать страницы с историей редактирования какой либо картинки.
ну просто можно откатиться, так же как по тексту - посмотреть старые версии картинки.
новое имя придумывать не надо - там просто есть ссылка "загрузить новую версию этой же картинки".
то есть даже не надо править какие либо ссылки в тексте статьи, где эта картинка иллюстрирует что либо - новая версия автоматически подгружается там, поскольку по ссылке всегда последняя версия.
по-моему можно ставить и ссылки на старые версии картинки. то есть, к примеру, делать страницы с историей редактирования какой либо картинки.
Красиво. А как быть с версионированием исходников этих картинок — vss/mdl и т.п.?
ну сам я просто скидывал более-менее стабильные версии исходных диаграмм в виде файлов на диск с новыми именами
наверное можно было бы соурс сейф или что-то подобное использовать, но потребности как то не возникало: задача откатиться и посмотреть различия есть, а задача откатиться и сделать другую ветку правок не возникала пока что, поэтому версионирования рендеров хватает.
и опять-таки, скажем в том же ARIS, в котором я строю диаграммы, есть свои какие то свои внутренние средства версионирования, просто пока не разбирался. Visio же, наверняка с VSS хорошо интегрироваться должен, всё ж одной компании продукты.
смешно было, когда в редакции журнала одного работал, там у нас при верстке были "макет последняя версия.qxp" "макет самая последняя версия.qxp" "макет последняя-распоследняя версия.qxp" "макет дальше уже некуда.qxp" и так далее :-) но за чек-инами и чек-аутами никто не следил, поэтому в итоге корректоры иногда рвали волосы на головах "я же уже правил это, почему опять эти же ошибки!"
наверное можно было бы соурс сейф или что-то подобное использовать, но потребности как то не возникало: задача откатиться и посмотреть различия есть, а задача откатиться и сделать другую ветку правок не возникала пока что, поэтому версионирования рендеров хватает.
и опять-таки, скажем в том же ARIS, в котором я строю диаграммы, есть свои какие то свои внутренние средства версионирования, просто пока не разбирался. Visio же, наверняка с VSS хорошо интегрироваться должен, всё ж одной компании продукты.
смешно было, когда в редакции журнала одного работал, там у нас при верстке были "макет последняя версия.qxp" "макет самая последняя версия.qxp" "макет последняя-распоследняя версия.qxp" "макет дальше уже некуда.qxp" и так далее :-) но за чек-инами и чек-аутами никто не следил, поэтому в итоге корректоры иногда рвали волосы на головах "я же уже правил это, почему опять эти же ошибки!"
У меня на практике было проблемой именно то, что приходилось где-то отдельно хранить версии исходных файлов и обеспечивать к ним совместный доступ. Мы использовали связку wiki+phpcollab (для файлов и задач). При этом постоянно возникала проблема с тем, что номера версий страниц в wiki и номера версий исходных файлов в phpcollab рассинхронизировались.
Половина опрошенных контроля версий не ведут - хороший показатель уровня культуры разработки.
Пользуемся SVN. Под Eclipse для нее есть совершенно превосходный плагин (Subclipse), работать очень удобно.
TortoiseCVS || TortoiseSVN - отличная обёртка в виде подменю в контекстном меню проводника.
Поскольку это всё потихоньку становится маленьким филиалом Slashdot и здесь любят богомерзкий линуксопенсорс, варианта Visual SourceSafe не предусмотрено.
А там кликать очень удобно. В CVS - неудобно.
А там кликать очень удобно. В CVS - неудобно.
CVS терпеть не могу за тормознутость при удалённых репах. В меру люблю Subversion, как "CVS done right", но последнее время ушёл для себя на bzr - быстро работает, всё умеет и можно выкладывать код на продакшн без всяких вывертов.
А что Borland StarTeam никто не использует? Там еще есть отличный плагин к Visual Studio
Rational Clear Case
Раньше использовали CVS, но 2 раза в год, когда переводили часы на летнее/зимнее время слетали все даты в исходниках, требовалось весь проект обновлять по-новой. Сейчас пользуем SVN, никаких проблем.
Рейшнал.
Вот, вспомнил! Кроме cvs (которой пользуюсь больше всего) и svn (на которую давно собираемся переходить) одно время был вынужден пользоваться системой Surround SCM. Впечатления от последней отрицательные (тормозная, глючная, неудобная) - так что не советую.
На работе - SourceSafe
использую mercurial, даже для своих маленьких поделок-на-коленке. а как иначе? удобно же...
Кстати, статистика статистикой, а какую систему посоветовал бы всезнающий all? А то на работе своя собственная, которая что CVS, что SVN как бык овцу кроет, а вот для любительских развлечений на стороне хотелось бы тоже что-то приличное подобрать...
Посмотрите на Perforce, может вам понравится. Правда он денег стоит. Если из бесплатных - наверное всё-таки Subversion.
PS: Я не всезнающий all, это только моё скромное мнение :)
PS: Я не всезнающий all, это только моё скромное мнение :)
А почему бы не использовать системы по типу Bugzilla, Trac где уже есть контроль версий, багтрекинг ,вики?
Visual Studio 2005 Team System.
Ибо решает практически все поставленные для ведения проекта задачи.
Ибо решает практически все поставленные для ведения проекта задачи.
С удовольствием почитал бы статью и даже на семинар бы сходил о системах контроля.
Сначала использовали bazaar (bzr), но из-за тормозов перешли на mercurial (hg).
А никто не подскажет где можно взять видеоуроки по установке SVN?
Не стоит ли и этот старый топик перенести в блог «Системы управления версиями»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используете ли вы систему контроля версий для разработки?