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