Pull to refresh

Comments 91

Если надо дополнить другими вариантами, пишите.
Ну хорошо - узнали, что среди голосовавших 50% используют svn. И что?
Ну как минимум - узнали, что треть голосовавших не пользуется, но хотело бы. А это повод написать статью, и может быть даже провести семинар :)
Лично я от хабра ожидал большего, чем ликбез. Те кому надо, себе уже СКВ подобрали. Статей в сети полно. В том числе на русском языке.
Мне будет проще сделать выбор при поиске :) потому как ставить надо, а с чего начать - хз.
Спасибо автору опроса.
а выбор систем контроля версий - настолько обширная тема?
имхо 1 дня для гугления вполне достаточно чтобы определиться с системой, для этого и хабра не надо
к тому же - этот опрос никакой смысловой нагрузки не несёт, разве что статистика...
А все равно приятно. Я смотрю вы не особо то пишете :) зато сколько критики.
не особо публикуюсь на хабре?
я просто не журналист и не переводчик
ps: ну а по правде - кроме "приятно" и "я теперь знаю что юзают хабровцы" ты из голосования что-нибудь почерпнул? только не лукавь!!! ;)
Ну вот я почерпнул (выше писал) - мне интересно, какие темы интересует людей в отрасли web-разработки. За что автору опроса спасибо.
Да. Мне особо не охота разбираться что ставить, а ставить надо. А большинство подскажет оптимальное решение, и я не запариваясь его использую.

Я тоже не журналист и не переводчик, именно поэтому то, что нравится - плюсую, а то что не нравится оставляю без внимания.
об оптимальности можно говорить только тогда, когда определён критерий, относительно которого можно сравнивать варианты
ты критерии не озвучил => об оптимальности говорить нет смысла ;)
большинство - может лишь сказать то, что юзают они. для того же, чтобы узнать, что лучше в твоей конкретной ситуации, нужно знать эту ситуацию
Добавьте минусов, пионэры. А то дяденьки вам не расскажут, зачем СКВ нужна.
Я прав - это пионэры :).
аналогично.
еще на TeamCity надо бы посмотреть, только времени пока нема, и стоимость обдумать... 199 с носа вроде и не дорого, но жаба давит :)
TeamCity это сильно больше чем система контроля версий...
именно по тому и хочется пощупать :)
не используем и не планируем.
какой бардак!
спасибо, нет ничего лучше чем rtfm со ссылкой)
А может кто-то вкратце рассказать что это и зачем? Много слышу, а с чего начать и какая практическая польза?
например, такая - для тех, что системами контроля версий не пользовался, при приеме на работу мы предлагаем зарплату на 20% меньше
Могу. Если кратко, то польза такая:

1. Сохраняется история изменений файлов (это полезно даже если "над проектом работает только один человек"). Это как бы бесконечное undo на каждый файл, с возможностью смотреть и сравнивать любые прошлые версии.

2. Если разработчиков несколько - видно, кто, когда и где менял тот или иной файл. Т.е. про каждую строчку кода в любом файле можно сказать, кем и когда она была написана или отредактирована.

3. Наконец, система контроля версий сама сливает правки, внесенные разными разработчиками. Т.е. двое могут одновременно править "один и тот же" файл, без опасности затереть изменения друг друга. После правки система или сама сольет изменения, или (если сама не сможет) - покажет кто что исправил и предложит разобраться человеку.
P.S. Об остальных преимуществах (а их хватает) лучше задумываться уже после первого знакомства ;)
На работе --- SVN (раньше был ужасный до невозможности SourceSafe). Дома --- git (всем рекомендую!). А почитать можно, как всегда, на википедии. (Хотя, честно говоря, не верится, что кто-то пишет программы без SCM системы).
Нескромный вопрос: почему дома -git?
Причин несколько:
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 для всего, что хочешь, не задумываясь над "администрированием". Для меня это --- плюс.
В случае с SVN шаг 3 куда больше будет! Сначала надо придумать, где хранить репозиторий (+ mkdir + cd), затем svnadmin create (+ параметры), затем checkout (после cd в new_project), причем я только с 3 раза угадывал, как надо зашифровать локальный путь.


Есть мнение, что вы не доконца прочли документ по осовам работы с svn, а (+ mkdir + cd) - это вообще не аргумент.
Рад за ваше мнение, но я его читал. Я написал о том, что нравится лично мне; никого переубеждать я не собираюсь. Не разводите флейм.
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 и читать именно ее?
тут вы неявно предполагаете очень короткие циклы и вообще итерациность как норму жизни

у нас пока всё иначе

с требованиями в текущем режиме работают аналитики

по мере готовности аналитики выгружают baseline, на его основании формируется исходный набор задач

дальнейшие изменения требований накапливаются, а не идут сразу в работу. как только требования baseline более-менее реализованы (процентов на 80-90), накоплены новые требования и на их основе порождаются новый набор задач. циклы - от месяца до недели.
В случае с длинными циклами и отсутствием итеративности я не вижу смысла использовать wiki.
А как ещё коллективно разрабатывать документацию и требования без привлечения специализированных инструментов? С пересылкой туда-сюда доковского файла? С извлечением его из SVN и правкой?

Wiki - это просто удобно.
Wiki — удобно для документации. Согласен.
Но система контроля версий все-таки в разу удобнее непосредственно для кода.
Думаю, что все-таки необходимо совмещать и то и другое.
Абсолютно верно. Держать файлы в SVN.

Опробованная методика. В случае, когда у нас не только голый текст, а зоопарк из doc/xls/vss/mdl и т.п. это, согласно лично моей практике, заметно удобнее wiki.

Кстати вопрос: как вы организовали работу с картинками? Для меня это было в wiki большим геморроем именно в плане версионности и удобства добавления.
Я к выявлению и фиксации требований заказчика и аналитиков подрядчика привлекаю. Хватит им мороки с wiki-синтаксисом, так вы предлагаете им ещё на каждый компьютер, откуда он будет работать, SVN-клиента ставить, обучать принципам check-in/check-out и т.д?

С картинками всё просто - они служат только для иллюстрации текста (если говорить о требованиях), и обновляются гораздо реже теста. Заказчик/эксперты картинки только смотрят и согласовывают/комментируют, но не правят.

Над инструментами совместного визуального рисования, что актуально, например, для моделей бизнес-процессов и UML, пока думаем. В сети есть только рисовалки и редакторы MindMap.

С картинками пока такой цикл - скопировать из среды моделирования в буфер, вставить в GIMP, оттуда сохранить и залить в MediaWiki через соответствующую кнопку. В нужно месте текста вставить или обновить ссылку на картинку.
Я привык считать что у аналитиков (пусть — у большей части) достаточно интеллекта, чтобы освоить концепцию checkin/checkout. :)

По поводу картинок не совсем понял:

1. Какова судьба исходных файлов? Что делать, если нужно вернуться на три версии назад по тексту и картинкам и начать заново?
2. Каждый раз нужно придумывать новое имя файла для картинки?
Лучший способ сократить затраты на какую-либо операцию - это не делать её вовсе.

В MW есть версионность изображений, но я ей не пользовался.
я пользовался версионированием картинок в медиавики
ну просто можно откатиться, так же как по тексту - посмотреть старые версии картинки.
новое имя придумывать не надо - там просто есть ссылка "загрузить новую версию этой же картинки".
то есть даже не надо править какие либо ссылки в тексте статьи, где эта картинка иллюстрирует что либо - новая версия автоматически подгружается там, поскольку по ссылке всегда последняя версия.
по-моему можно ставить и ссылки на старые версии картинки. то есть, к примеру, делать страницы с историей редактирования какой либо картинки.
Красиво. А как быть с версионированием исходников этих картинок — vss/mdl и т.п.?
ну сам я просто скидывал более-менее стабильные версии исходных диаграмм в виде файлов на диск с новыми именами
наверное можно было бы соурс сейф или что-то подобное использовать, но потребности как то не возникало: задача откатиться и посмотреть различия есть, а задача откатиться и сделать другую ветку правок не возникала пока что, поэтому версионирования рендеров хватает.
и опять-таки, скажем в том же ARIS, в котором я строю диаграммы, есть свои какие то свои внутренние средства версионирования, просто пока не разбирался. Visio же, наверняка с VSS хорошо интегрироваться должен, всё ж одной компании продукты.

смешно было, когда в редакции журнала одного работал, там у нас при верстке были "макет последняя версия.qxp" "макет самая последняя версия.qxp" "макет последняя-распоследняя версия.qxp" "макет дальше уже некуда.qxp" и так далее :-) но за чек-инами и чек-аутами никто не следил, поэтому в итоге корректоры иногда рвали волосы на головах "я же уже правил это, почему опять эти же ошибки!"
У меня на практике было проблемой именно то, что приходилось где-то отдельно хранить версии исходных файлов и обеспечивать к ним совместный доступ. Мы использовали связку wiki+phpcollab (для файлов и задач). При этом постоянно возникала проблема с тем, что номера версий страниц в wiki и номера версий исходных файлов в phpcollab рассинхронизировались.
Половина опрошенных контроля версий не ведут - хороший показатель уровня культуры разработки.
Пользуемся SVN. Под Eclipse для нее есть совершенно превосходный плагин (Subclipse), работать очень удобно.
Это будет (если будет) следующим опросом на эту тему. Потому что клиент тоже важный аспект системы контроля версий.
не забудьте включить моего любимого клиента: svn.exe :)
Ага, и /usr/bin/cvs пожалуйста тоже ;)
Поскольку это всё потихоньку становится маленьким филиалом Slashdot и здесь любят богомерзкий линуксопенсорс, варианта Visual SourceSafe не предусмотрено.

А там кликать очень удобно. В CVS - неудобно.
К сожалению, я раскатал губищи, а редактировать опрос нельзя :(

Я, действительно, не знал про существование такой системы от Microsoft (хотя, догадывался).
Она бесплатна? (:
Если не ошибаюсь, это часть Visual Studio. Со всеми лицензионными вытекающими.

Сам не разработчик, но периодически использую. Удобно.
UFO just landed and posted this here
Охотно верю.

Но кликаю в пределах корпоративных стандартов.
CVS терпеть не могу за тормознутость при удалённых репах. В меру люблю Subversion, как "CVS done right", но последнее время ушёл для себя на bzr - быстро работает, всё умеет и можно выкладывать код на продакшн без всяких вывертов.
А что Borland StarTeam никто не использует? Там еще есть отличный плагин к Visual Studio
Раньше использовали CVS, но 2 раза в год, когда переводили часы на летнее/зимнее время слетали все даты в исходниках, требовалось весь проект обновлять по-новой. Сейчас пользуем SVN, никаких проблем.
Вот, вспомнил! Кроме cvs (которой пользуюсь больше всего) и svn (на которую давно собираемся переходить) одно время был вынужден пользоваться системой Surround SCM. Впечатления от последней отрицательные (тормозная, глючная, неудобная) - так что не советую.
использую mercurial, даже для своих маленьких поделок-на-коленке. а как иначе? удобно же...
Кстати, статистика статистикой, а какую систему посоветовал бы всезнающий all? А то на работе своя собственная, которая что CVS, что SVN как бык овцу кроет, а вот для любительских развлечений на стороне хотелось бы тоже что-то приличное подобрать...
Посмотрите на Perforce, может вам понравится. Правда он денег стоит. Если из бесплатных - наверное всё-таки Subversion.

PS: Я не всезнающий all, это только моё скромное мнение :)
Спасибо, попробую!
А почему бы не использовать системы по типу Bugzilla, Trac где уже есть контроль версий, багтрекинг ,вики?
А почему бы не использовать системы по типу Bugzilla, Trac где уже есть контроль версий, багтрекинг ,вики?

Разве Bugzilla и Trac предоставляют собственный Version Control System? Я был уверен, что они интегрируются с существующими.
Trac использует subversion.
Visual Studio 2005 Team System.
Ибо решает практически все поставленные для ведения проекта задачи.
С удовольствием почитал бы статью и даже на семинар бы сходил о системах контроля.
UFO just landed and posted this here
UFO just landed and posted this here
Сначала использовали bazaar (bzr), но из-за тормозов перешли на mercurial (hg).
А никто не подскажет где можно взять видеоуроки по установке SVN?
Не стоит ли и этот старый топик перенести в блог «Системы управления версиями»?
Sign up to leave a comment.

Articles