Какие системы управления версиями вы используете? (В реальной работе. Опрос для конференции).

[denver]

Для тех кто уже отдал голос, вот правильные ответы :) А вообще очень любопытна годовая тенденция.

[Pilot34]

а зачем еще раз-то? :-/ Неужто думаете что-то изменилось?

[diamant]

год прошёл, доля CVS должна упасть, Git — подрасти, SVN без изменений :)

[Screatch]

/me Поглядывая на дату предыдущего поста.
Вы специально день что ли отсчитывали?)

[denver]

Отсутсвие результата — тоже результат ;)

В любом случае прогресс есть, радует что под напором таких обсуждений CVS всё быстрее уходит в прошлое, а git/mercurial потихоньку растут. SVN еще не собирается сдавать — это тоже много о чём говорит.

[iOrange]

Жаль нельзя выбрать несколько вариантов — у меня это SVN + Mercurial

[bytemdfab]

Аналогично. Но проголосовал за SVN, так как она у нас основная, а к Mercurial пока присматриваемся

[soroktu]

поддерживаю. CVS + Subversion

[naum]

удивительно (хотя чего удивительно) — вас минусуют за то, что вы используете то, что не особо то и оно и не смотря, что половина того как бы и оно, вторая половина вообще не то. черт побери :)

[mente]

Согласен, svn + git

[SeVit]

SVN + Bazaar

[yul]

Притом, вопрос подразумевает несколько вариантов.

[aimodify]

то же самое.

[Homakov]

ткните в матчасть — как в одном проекте можно работать в двух cvs? Т.е. у вас они как то интегрированы? Или же в каждом проекте разные?

[iOrange]

В опросе звучит «В реальной работе» а не «В одном проекте». Для старых + некоторых новых — SVN. Остальное — Mercurial

[medvoodoo]

тот же svn можно нормально более-менее подружить с git, у нас для старых проектов svn продолжается, для новых git

[lair]

Аналогично, на части проектов — TFS, на части — SVN.

[u_story]

SVN + Perforce

[timon_sk]

аналогичная комбинация. на работе используем Perforce, а для собственных проектов держу SVN сервер

[seymour]

интересно почему все еще столько людей используют svn, а не git | mercurial… php-шники? а cvs — это вообще жесть :) шел 2010 год…

[iOrange]

Крупные компании очень инертны :( Сам в такой работаю

[narma]

Можно использовать git поверх svn, никто даже не заметит что вы работаете через git. И волки сыты, и овцы целы.

[evilbloodydemon]

полноценной работой назвать это конечно сложно — мерджи использовать нельза, только ребейз, но вполне себе вариант

[swk]

Не будет плюшек с трехточечными мержами, но в целом — работает.
Так и живем :)

[argos]

И меркуриал тоже можно :)

[seymour]

снимаю шляпу :)

[seymour]

php-шники минусуют? :D

[Homakov]

в каждом из нас живет пхпшник. Да, аноним, я знаю твой первый ЯП :)

[Sap_ru]

у git нет кроссплатформенности.
у mercurial всё хорошо, но размеры локальных репозитариев растут со страшной силой (особенно если в проект входят бинарные данные). Полюс, репозитарий является фактически рабочей папкой пректа, из-за чего последние тоже становятся слишком тяжёлыми. Плюс, создание новой копии связано с получением полной копии репозитаория.
В общем — не для всех проектов и применений.

[seymour]

>> у git нет кроссплатформенности
года 3-4 назад пользовался git под виндой, сейчас ежедневно пользуюсь git на маке и линуксе. с какой платформой у git-а проблемы?

[Sap_ru]

ну, пару лет назад под виндой с git не заладилось :) Видимо что-поменялось — нужно посмотреть :)

[DevMan]

Можете не смотреть — работает, проверено :)

[DevMan]

Я из коносли работаю.
Из того, что знаю:
code.google.com/p/tortoisegit/
www.syntevo.com/smartgit/index.html

[DevMan]

Последний вроде как совсем не плох.

[DevMan]

Я бы не назвал это недостатком — цена на него (как по мне он намного удобнее tortoisegit) вполне доступная бизнес-клиентам, а для некоммерческого использования он вовсе бесплатен.
Плюс он кроссплатформен.

[Sap_ru]

Ладно, уговорили — перехожу. :)

[DevMan]

3/4 офиса сидит на git из win.

[immaculate]

Клонирование создает локальную копию созданием hardlinks. Быстро и не занимает места.

[Sap_ru]

Я уже говорил про кросс-платформенность? И я имел ввиду копию удалённого репозитария.

[DevMan]

И что с ней не так?

[immaculate]

Достаточно иметь один клон удаленного репозитория, и уже его клонировать сколько угодно локально. Необязательно для каждого клона клонировать удаленный репозиторий.

[swk]

Может быть я что-то не понимаю, но как vcs может быть «обвязана» с хранящимся в ней контентом?

[swk]

Понятно. Не знал что в друпале все так печально.
Я категорически не согласен с моделью в которой VCS кроме «хранения версий» берет на себя задачи build-сервера, code-review и issue-треккера.
Скрещивать козу с бояном — это как минимум не разумно.

[noRerih]

Помимо того, что вы несогласны и это «не разумно», можете аргументировать?) Аргументы @impersona со коллеги, насколько я понимаю: «улучшение качества кода при снижении скорости его попадания в репозиторий», что звучит вполне разумно.

[swk]

Я считаю что каждый элемент инфраструктуры должен выполнять свою задачу.

Почему система контроля версия когда ей говорит «комить» прогоняет тесты?
Этим должен заниматься билд-сервер. На VCS завязан только триггер билдсервера, запускающий прогон тестов. Поменяли систему контроля версий — изменили один пункт настроек билдсервера, никаких проблем.

Почему за ревью код следит система контроля версий? Почему она определяет из какой ветки можно собирать релиз, а из какой нельзя?
Намного более правильная схема: выбрали в issue tracker тэг на основании которого собран релиз, issue tracker запросил у fisheye (или аналогичной системы), все ли коммиты имеют ревью, если не все, то релиз выпустить нельзя. И опять-таки, никаких скритов написанных на коленке и удобные интерфейсы.

Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.

[impersona]

Сколько людей — столько мнений, и это хорошо :)

Моё мнение — инфраструктуру проекта надо рассматривать целиком.

Можно набирать её из компонент (cvs,ci, багтрекер) и интегрировать, а можно (разумеется, если есть время-ресурсы) допилить одну из vcs под свои нужды. главное, чтобы всё вместе хорошо работало и было поддерживаемым.

> Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.

вы наверное и аннотации не любите :) и инструкции не по сборке, а по менеджменту этого кода — кто может менять, что делать при изменениях, проч.

это как со конфигурацией Spring'a (я джавер) — можно вынести в XML, можно сделать аннотациями в коде. В коде имхо удобнее.

[swk]

Аннотации имеют непосредственное отношение к коду, а менеджмент — это другой вопрос.

Да, разумеется при достаточном количестве интузиазма и ресурсов можно свернуть с протоптанного пути и сделать по-своему, но рано или поздно все равно придется интегрироваться как минимум в багтреккер, и тогда опять — интузиазм, ресурсы…

оффтопик: использовать спринговые аннотации в коде удобнее до определенного момнета, пока проект не разрастется. Когда нужно работать с десятками модулей и сотнями классов, то спринговые/хибернейтовые анотации превращаются в спагетти.
Но в целом к аннотациям я отношусь очень хорошо :)))

[kurokikaze]

Я думаю у любого крупного проекта есть такие завязки для облегчения совместной работы. Есть хорошая статья о том как PostgreSQL переходили с CVS на Git — как раз по теме.

[kurokikaze]

CVS + Git

[naum]

Простите, а почему CVS? С чем связано? Очень контрастно видеть CVS и Git рядом.

[kurokikaze]

Одну использую по правилам компании, вторую изучаю просто для себя и потихоньку применяю. Догадаетесь где какая? :)

[naum]

Это понятно :) А с чем связано использование CVS в компании? Высокая стоимость смены инфраструктуры (наличие решений по расширению возможностей CVS, определенного ПО, глубокая интеграция & etc.) или какой-то принципиальный момент? Расскажите подробнее!

[kurokikaze]

Сила привычки скорее всего и нежелание геморроиться со старыми репозиториями. Более новые проекты компании уже используют SVN. Особо глубокой интеграции нет.

Я сейчас ещё с gitosis работаю — смотрю можно ли сделать так чтобы я работал с git а какой нибудь скрипт автоматически отправлял мои правки в CVS.

[halyavin]

SVN+Git+Mercurial :(

[dohlik]

SVN (для работы на «дядю») + GIT (для себя)

[zloddey]

аналогично

[yonyonson]

CVS + MS Team Foundation Server + Git
Основная CVS.

[moooV]

Не пользуюсь системами контроля версий.

[kronos]

Садитесь, два.

[naryl]

darcs же.

[argos]

Толсто же, и зелено же… Написано же — в реальной работе же.

[naryl]

Толсто же и зелено же, утверждать, что это толсто же и зелено же же.

В реальной же работе же и используется же.

Если, конечно, автор опроса не хочет «в реальной работе» заменить на «в оплачиваемой по часам работе».

[argos]

Писать на хаскеле — это не работа, это анти-работа :) То есть развлечение…

[naryl]

Я не пишу darcs. Я его использую.

[AlexAkimov]

В DevExpress мы используем собственную систему контроля версий.

[Pilot34]

я бы постеснялся о таком говорить)

[casey]

Вот-вот! А вроде солидная компания…

[AlexAkimov]

Был вопрос — был ответ :-) Главная же цель опроса — получить общую картину, так зачем мне скрывать?

А так, каждый исходит из своих сценариев работы и из своих задач. Для наших задач нам потребовалось сделать что-то своё, благо были ресурсы и время. И нам это сильно помогает в работе, так что чего тут стесняться?

Будет время, может расскажем об этом поподробнее…

[Zubchick]

видимо у остальных систем есть фатальный недостаток?)

[fledgling]

Они сложные!

[pxx]

Корпоративно TFS, для своих проектов SVN

[dmbreaker]

SVN + Mercurial

[casey]

Mercurial, но для взаимодействия с админами есть скрипт перелива тэга в корпоративный svn. Крупные компании, инертность, да, это ужасно :-(

[narma]

Везде git, счастье то какое. На текущем месте работы svn используется только как система для хранения/обновления релизов.

[impersona]

У нас самописная система на основе CVS.

Звучит страшно, но по факту пользоваться удобно, тк за несколько лет было хорошо допилено:
— дешевые бранчи, приемлемый merge
— удобный gui
— локально ничего не хранится — можно на машине коллеги за секунду переключиться в свой workspace и вместе с ним продолжить работать над незакоммиченными изменениями

встроенная поддержка:
— code review
— run-tests-before-commit — нельзя закоммитить что-то, что ломает тесты
— second-pair-of-yes check — все коммиты для релиза должны быть подтверждены кем-то еще, кроме разрабочка

То есть, что хорошо сделано — поддержка тех самых agile software development best practices на уровне VCS.

Каких-то из них поддерживаются в рекомендательном виде: зарелизить без second-pair-of-yes check можно, но всем будут разосланы емайлы с большими красными буквами — то есть на это надо иметь хорошую причину (типа всё упало ночью и нужен срочный багфикс).

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

[Sky3d]

— run-tests-before-commit — нельзя закоммитить что-то, что ломает тесты

А можно поинтересоваться насчет времени прохождения тестов перед закладкой?

— second-pair-of-yes check — все коммиты для релиза должны быть подтверждены кем-то еще, кроме разрабочка

Как осуществляется выбор того, кто должен проводить ревью кода?

[impersona]

> А можно поинтересоваться насчет времени прохождения тестов перед закладкой?
Тесты помечены тагами. Перед коммитом запускаются те, которые не имеют тагов типа «integration» или «slow». Соотсветсвенно есть возможность регулировать компромисс между coverage и временем коммита.

> Как осуществляется выбор того, кто должен проводить ревью кода?
В заголовке файлов есть поля, которые парсятся при коммите.
Поля типа:
— email'ы разработчиков/группы разработчиков, кто может делать code review / approval
— email'ы группы, куда пост-коммит отсылаются diff'ы-уведомления
— Test suites, которые будут запускаться (кроме testsuit'ов по умолчанию)
и проч.

также всё это можно указать в отдельном файле со специальным именем, тогда настройки будут действовать для всех файлов в директории.

[Sky3d]

Перед коммитом запускаются те, которые не имеют тагов типа «integration»

Существует ситуация когда должен быть заложен код, в результате которых перестают работать тесты. Как я понимаю, вы правите тесты, помечаете их тэгом Integration и закладываете совместно с кодом. Как налажен процесс того, кто потом очистит тэги, что бы тесты не пропускались перед последующими закладками?

В заголовке файлов есть поля, которые парсятся при коммите.

О каких файлах идет речь?

[impersona]

согласен, такие ситуации бывают, но в принципе это уже исключительная ситуация, типа «поменялись требования, тесты менять долго, а функционал нужен сейчас».

в таких случаях тесты помечаются как disabled, т.е. они по-прежнему видны в continuous integration, но не запускаются. А вот их обратное их включение — уже на совести того, кто отключил ;)

> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.

[mviorno]

Гм, нескромный вопрос, а сколько примерно у вас коммитов в неделю, раз у вас получается делать run-tests-before-commit и ревью?

[impersona]

коммитов много (на проекте порядка 80 разработчиков в 10-12 группах). если грубо прикинуть — 1-10 коммитов в день от каждого.

но времени тесты и review занимают немного — писать код всё равно медленнее, чем читать и запускать ;)

[mviorno]

Ясно. А у нас >5000 коммитов в неделю нормальная ситуация. Ну и прогон тестов от 10 минут и выше. Даже при таких временах велика вероятность получить новую пачку изменений в репозиторий за время прогона тестов перед коммитом.

[impersona]

ну, практически получается задержка в 20-30 секунд перед коммитом — что имхо приемлемо (как раз за это время успеешь ещё раз подумать — всё ли правильно коммитится))

время на ревью — открыть ссылку из почты, просмотреть изменения, нажать кнопочку «согласен» или написать «кг-ам» в комментариях. задержка ревью обычно 5-30 минут.

я не навязываю, просто для нашего проекта-группы это работает. у вас может быть другой проект и другие реалии.

да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.

[AlexandrZ]

А в каждом комите плюс еще операций правок порядка 5-10 (в среднем), так?

[impersona]

нет. обычно без правок, иногда 1-2 правки.
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.

опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)

[skipfish]

mercurial на работе, git для себя.

[Zubchick]

что так не нравится меркуриал? Или из-за гитхаба?

[skipfish]

из-за гитхаба :)

[argos]

А bitbucket чем не рулит?

[skipfish]

bitbucket рулит, хотя бы тем, что он дешевле. Но на гитхабе больше рельсовых гемв, плагинов и прочего, а я для себя как раз этим и занимаюсь

плюс внешне конечно больше нравится гитхаб )

[LexL]

Из-за питона :)

[Olegbl4]

git+svn

[ulmen]

git, git-svn

[LexL]

И под Vs.Net — VisualSVN… Когда уже VisualGit выпустят?

[frol]

Уже есть Git Extensions ( code.google.com/p/gitextensions/ ) интегрируеться с VS 2005,2008,2010 + Хороший UI для отображения веток и тд.

[GeniyZ]

В нашей организации используется VSS — это пиздецЪ!
А вообще я сторонник GIT и удивлён, что он не лидирует.

[MyraJKee]

сравнительно молод он еще… )
Юзаю Git.

[Push_Ok]

svn+git

[JoseArcadio]

Mercurial. т. к. распределенный, кросплатформенный, и имеет удобный UI.

[Nekuromento]

На работе ужасный MS-VSS, для своих проектов использую Mercurial

[dmc0re]

Личные проекты на GIT, корпоративные на SVN.

[torkve]

svn+bzr

[mr_avi]

В основном SVN, но есть и Mercurial

[Rezzet]

git+mercurial

[elisium]

SVN + GIT

[iwuvjhdva]

git, mercurial, svn

[veitmen]

TFS

[SowingSadness]

все время посматриваю на неё, но ни разу еще не получалось использовать. :-(

[ergil]

git+svn

[Ins1ne]

хотелось бы только Git, но приходится юзать Git + SVN

[AlexTikhonov]

Интересно, а есть кто-то, кто еще пользуется AccuRev?

П.С. не понимаю зачем постаить повторяющиеся ответы в виде комментов, когда достаточно нажать +1 или в худшем случае (если нет кармы) как ответ. А то мне кажется что как минимум «git+svn» повторялись несколько раз.

[DarthBender]

IBM Rational Team Concert. В купе с разработкой под Eclipse неожиданно оказалась много удобнее SVN + Subversive.

[korsakov]

SVN, смотрим в сторону Git.
4-летний проект на PHP/Python

[belonesox]

Теперь этот опрос наверно, будет ежегодной традицией. Можно будет отслеживать тренды. А для какой конференции вы сделали этот опрос? Куда пойдут результаты?

[denver]

Я просто скопировал всё из вашего опроса как есть ;) решил оставить заголовок тем же, чтобы удобнее было сравнивать результаты.