Как стать автором
Обновить

Комментарии 128

а зачем еще раз-то? :-/ Неужто думаете что-то изменилось?
год прошёл, доля CVS должна упасть, Git — подрасти, SVN без изменений :)
/me Поглядывая на дату предыдущего поста.
Вы специально день что ли отсчитывали?)
Отсутсвие результата — тоже результат ;)

В любом случае прогресс есть, радует что под напором таких обсуждений CVS всё быстрее уходит в прошлое, а git/mercurial потихоньку растут. SVN еще не собирается сдавать — это тоже много о чём говорит.
Жаль нельзя выбрать несколько вариантов — у меня это SVN + Mercurial
Аналогично. Но проголосовал за SVN, так как она у нас основная, а к Mercurial пока присматриваемся
поддерживаю. CVS + Subversion
удивительно (хотя чего удивительно) — вас минусуют за то, что вы используете то, что не особо то и оно и не смотря, что половина того как бы и оно, вторая половина вообще не то. черт побери :)
Согласен, svn + git
SVN + Bazaar
Притом, вопрос подразумевает несколько вариантов.
НЛО прилетело и опубликовало эту надпись здесь
то же самое.
ткните в матчасть — как в одном проекте можно работать в двух cvs? Т.е. у вас они как то интегрированы? Или же в каждом проекте разные?
В опросе звучит «В реальной работе» а не «В одном проекте». Для старых + некоторых новых — SVN. Остальное — Mercurial
тот же svn можно нормально более-менее подружить с git, у нас для старых проектов svn продолжается, для новых git
Аналогично, на части проектов — TFS, на части — SVN.
аналогичная комбинация. на работе используем Perforce, а для собственных проектов держу SVN сервер
интересно почему все еще столько людей используют svn, а не git | mercurial… php-шники? а cvs — это вообще жесть :) шел 2010 год…
Крупные компании очень инертны :( Сам в такой работаю
Можно использовать git поверх svn, никто даже не заметит что вы работаете через git. И волки сыты, и овцы целы.
полноценной работой назвать это конечно сложно — мерджи использовать нельза, только ребейз, но вполне себе вариант
Не будет плюшек с трехточечными мержами, но в целом — работает.
Так и живем :)
И меркуриал тоже можно :)
я php-шник и использую Git. прошу оставить предрасудки :)
снимаю шляпу :)
php-шники минусуют? :D
в каждом из нас живет пхпшник. Да, аноним, я знаю твой первый ЯП :)
у git нет кроссплатформенности.
у mercurial всё хорошо, но размеры локальных репозитариев растут со страшной силой (особенно если в проект входят бинарные данные). Полюс, репозитарий является фактически рабочей папкой пректа, из-за чего последние тоже становятся слишком тяжёлыми. Плюс, создание новой копии связано с получением полной копии репозитаория.
В общем — не для всех проектов и применений.
>> у git нет кроссплатформенности
года 3-4 назад пользовался git под виндой, сейчас ежедневно пользуюсь git на маке и линуксе. с какой платформой у git-а проблемы?
ну, пару лет назад под виндой с git не заладилось :) Видимо что-поменялось — нужно посмотреть :)
Можете не смотреть — работает, проверено :)
НЛО прилетело и опубликовало эту надпись здесь
Последний вроде как совсем не плох.
НЛО прилетело и опубликовало эту надпись здесь
Я бы не назвал это недостатком — цена на него (как по мне он намного удобнее tortoisegit) вполне доступная бизнес-клиентам, а для некоммерческого использования он вовсе бесплатен.
Плюс он кроссплатформен.
НЛО прилетело и опубликовало эту надпись здесь
Ладно, уговорили — перехожу. :)
3/4 офиса сидит на git из win.
Клонирование создает локальную копию созданием hardlinks. Быстро и не занимает места.
Я уже говорил про кросс-платформенность? И я имел ввиду копию удалённого репозитария.
И что с ней не так?
Достаточно иметь один клон удаленного репозитория, и уже его клонировать сколько угодно локально. Необязательно для каждого клона клонировать удаленный репозиторий.
НЛО прилетело и опубликовало эту надпись здесь
Может быть я что-то не понимаю, но как vcs может быть «обвязана» с хранящимся в ней контентом?
НЛО прилетело и опубликовало эту надпись здесь
Понятно. Не знал что в друпале все так печально.
Я категорически не согласен с моделью в которой VCS кроме «хранения версий» берет на себя задачи build-сервера, code-review и issue-треккера.
Скрещивать козу с бояном — это как минимум не разумно.
Помимо того, что вы несогласны и это «не разумно», можете аргументировать?) Аргументы @impersona со коллеги, насколько я понимаю: «улучшение качества кода при снижении скорости его попадания в репозиторий», что звучит вполне разумно.
Я считаю что каждый элемент инфраструктуры должен выполнять свою задачу.

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

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

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

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

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

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

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

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

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

оффтопик: использовать спринговые аннотации в коде удобнее до определенного момнета, пока проект не разрастется. Когда нужно работать с десятками модулей и сотнями классов, то спринговые/хибернейтовые анотации превращаются в спагетти.
Но в целом к аннотациям я отношусь очень хорошо :)))
Я думаю у любого крупного проекта есть такие завязки для облегчения совместной работы. Есть хорошая статья о том как PostgreSQL переходили с CVS на Git — как раз по теме.
Простите, а почему CVS? С чем связано? Очень контрастно видеть CVS и Git рядом.
Одну использую по правилам компании, вторую изучаю просто для себя и потихоньку применяю. Догадаетесь где какая? :)
Это понятно :) А с чем связано использование CVS в компании? Высокая стоимость смены инфраструктуры (наличие решений по расширению возможностей CVS, определенного ПО, глубокая интеграция & etc.) или какой-то принципиальный момент? Расскажите подробнее!
Сила привычки скорее всего и нежелание геморроиться со старыми репозиториями. Более новые проекты компании уже используют SVN. Особо глубокой интеграции нет.

Я сейчас ещё с gitosis работаю — смотрю можно ли сделать так чтобы я работал с git а какой нибудь скрипт автоматически отправлял мои правки в CVS.
SVN (для работы на «дядю») + GIT (для себя)
аналогично
CVS + MS Team Foundation Server + Git
Основная CVS.
Не пользуюсь системами контроля версий.
Садитесь, два.
Толсто же, и зелено же… Написано же — в реальной работе же.
Толсто же и зелено же, утверждать, что это толсто же и зелено же же.

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

Если, конечно, автор опроса не хочет «в реальной работе» заменить на «в оплачиваемой по часам работе».
Писать на хаскеле — это не работа, это анти-работа :) То есть развлечение…
Я не пишу darcs. Я его использую.
В DevExpress мы используем собственную систему контроля версий.
я бы постеснялся о таком говорить)
Вот-вот! А вроде солидная компания…
Был вопрос — был ответ :-) Главная же цель опроса — получить общую картину, так зачем мне скрывать?

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

Будет время, может расскажем об этом поподробнее…
НЛО прилетело и опубликовало эту надпись здесь
видимо у остальных систем есть фатальный недостаток?)
Они сложные!
Корпоративно TFS, для своих проектов SVN
Mercurial, но для взаимодействия с админами есть скрипт перелива тэга в корпоративный svn. Крупные компании, инертность, да, это ужасно :-(
Везде git, счастье то какое. На текущем месте работы svn используется только как система для хранения/обновления релизов.
НЛО прилетело и опубликовало эту надпись здесь
У нас самописная система на основе 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.
— run-tests-before-commit — нельзя закоммитить что-то, что ломает тесты

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

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

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

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

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

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

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

> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.
Гм, нескромный вопрос, а сколько примерно у вас коммитов в неделю, раз у вас получается делать run-tests-before-commit и ревью?
коммитов много (на проекте порядка 80 разработчиков в 10-12 группах). если грубо прикинуть — 1-10 коммитов в день от каждого.

но времени тесты и review занимают немного — писать код всё равно медленнее, чем читать и запускать ;)
Ясно. А у нас >5000 коммитов в неделю нормальная ситуация. Ну и прогон тестов от 10 минут и выше. Даже при таких временах велика вероятность получить новую пачку изменений в репозиторий за время прогона тестов перед коммитом.
ну, практически получается задержка в 20-30 секунд перед коммитом — что имхо приемлемо (как раз за это время успеешь ещё раз подумать — всё ли правильно коммитится))

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

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

да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.
А в каждом комите плюс еще операций правок порядка 5-10 (в среднем), так?
нет. обычно без правок, иногда 1-2 правки.
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.

опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)
mercurial на работе, git для себя.
что так не нравится меркуриал? Или из-за гитхаба?
из-за гитхаба :)
А bitbucket чем не рулит?
bitbucket рулит, хотя бы тем, что он дешевле. Но на гитхабе больше рельсовых гемв, плагинов и прочего, а я для себя как раз этим и занимаюсь

плюс внешне конечно больше нравится гитхаб )
Из-за питона :)
НЛО прилетело и опубликовало эту надпись здесь
И под Vs.Net — VisualSVN… Когда уже VisualGit выпустят?
Уже есть Git Extensions ( code.google.com/p/gitextensions/ ) интегрируеться с VS 2005,2008,2010 + Хороший UI для отображения веток и тд.
НЛО прилетело и опубликовало эту надпись здесь
В нашей организации используется VSS — это пиздецЪ!
А вообще я сторонник GIT и удивлён, что он не лидирует.
сравнительно молод он еще… )
Юзаю Git.
Mercurial. т. к. распределенный, кросплатформенный, и имеет удобный UI.
На работе ужасный MS-VSS, для своих проектов использую Mercurial
Личные проекты на GIT, корпоративные на SVN.
В основном SVN, но есть и Mercurial
НЛО прилетело и опубликовало эту надпись здесь
все время посматриваю на неё, но ни разу еще не получалось использовать. :-(
хотелось бы только Git, но приходится юзать Git + SVN
Интересно, а есть кто-то, кто еще пользуется AccuRev?

П.С. не понимаю зачем постаить повторяющиеся ответы в виде комментов, когда достаточно нажать +1 или в худшем случае (если нет кармы) как ответ. А то мне кажется что как минимум «git+svn» повторялись несколько раз.
IBM Rational Team Concert. В купе с разработкой под Eclipse неожиданно оказалась много удобнее SVN + Subversive.
SVN, смотрим в сторону Git.
4-летний проект на PHP/Python
НЛО прилетело и опубликовало эту надпись здесь
Теперь этот опрос наверно, будет ежегодной традицией. Можно будет отслеживать тренды. А для какой конференции вы сделали этот опрос? Куда пойдут результаты?
Я просто скопировал всё из вашего опроса как есть ;) решил оставить заголовок тем же, чтобы удобнее было сравнивать результаты.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории