Comments 128
Для тех кто уже отдал голос, вот правильные ответы :) А вообще очень любопытна годовая тенденция.
а зачем еще раз-то? :-/ Неужто думаете что-то изменилось?
год прошёл, доля CVS должна упасть, Git — подрасти, SVN без изменений :)
Отсутсвие результата — тоже результат ;)
В любом случае прогресс есть, радует что под напором таких обсуждений CVS всё быстрее уходит в прошлое, а git/mercurial потихоньку растут. SVN еще не собирается сдавать — это тоже много о чём говорит.
В любом случае прогресс есть, радует что под напором таких обсуждений CVS всё быстрее уходит в прошлое, а git/mercurial потихоньку растут. SVN еще не собирается сдавать — это тоже много о чём говорит.
Жаль нельзя выбрать несколько вариантов — у меня это SVN + Mercurial
Аналогично. Но проголосовал за SVN, так как она у нас основная, а к Mercurial пока присматриваемся
поддерживаю. CVS + Subversion
Согласен, svn + git
SVN + Bazaar
Притом, вопрос подразумевает несколько вариантов.
то же самое.
ткните в матчасть — как в одном проекте можно работать в двух cvs? Т.е. у вас они как то интегрированы? Или же в каждом проекте разные?
Аналогично, на части проектов — TFS, на части — SVN.
SVN + Perforce
интересно почему все еще столько людей используют svn, а не git | mercurial… php-шники? а cvs — это вообще жесть :) шел 2010 год…
Крупные компании очень инертны :( Сам в такой работаю
php-шники минусуют? :D
у git нет кроссплатформенности.
у mercurial всё хорошо, но размеры локальных репозитариев растут со страшной силой (особенно если в проект входят бинарные данные). Полюс, репозитарий является фактически рабочей папкой пректа, из-за чего последние тоже становятся слишком тяжёлыми. Плюс, создание новой копии связано с получением полной копии репозитаория.
В общем — не для всех проектов и применений.
у mercurial всё хорошо, но размеры локальных репозитариев растут со страшной силой (особенно если в проект входят бинарные данные). Полюс, репозитарий является фактически рабочей папкой пректа, из-за чего последние тоже становятся слишком тяжёлыми. Плюс, создание новой копии связано с получением полной копии репозитаория.
В общем — не для всех проектов и применений.
>> у git нет кроссплатформенности
года 3-4 назад пользовался git под виндой, сейчас ежедневно пользуюсь git на маке и линуксе. с какой платформой у git-а проблемы?
года 3-4 назад пользовался git под виндой, сейчас ежедневно пользуюсь git на маке и линуксе. с какой платформой у git-а проблемы?
ну, пару лет назад под виндой с git не заладилось :) Видимо что-поменялось — нужно посмотреть :)
Можете не смотреть — работает, проверено :)
Я из коносли работаю.
Из того, что знаю:
code.google.com/p/tortoisegit/
www.syntevo.com/smartgit/index.html
Из того, что знаю:
code.google.com/p/tortoisegit/
www.syntevo.com/smartgit/index.html
3/4 офиса сидит на git из win.
Клонирование создает локальную копию созданием hardlinks. Быстро и не занимает места.
Может быть я что-то не понимаю, но как vcs может быть «обвязана» с хранящимся в ней контентом?
Понятно. Не знал что в друпале все так печально.
Я категорически не согласен с моделью в которой VCS кроме «хранения версий» берет на себя задачи build-сервера, code-review и issue-треккера.
Скрещивать козу с бояном — это как минимум не разумно.
Я категорически не согласен с моделью в которой VCS кроме «хранения версий» берет на себя задачи build-сервера, code-review и issue-треккера.
Скрещивать козу с бояном — это как минимум не разумно.
Помимо того, что вы несогласны и это «не разумно», можете аргументировать?) Аргументы @impersona со коллеги, насколько я понимаю: «улучшение качества кода при снижении скорости его попадания в репозиторий», что звучит вполне разумно.
Я считаю что каждый элемент инфраструктуры должен выполнять свою задачу.
Почему система контроля версия когда ей говорит «комить» прогоняет тесты?
Этим должен заниматься билд-сервер. На VCS завязан только триггер билдсервера, запускающий прогон тестов. Поменяли систему контроля версий — изменили один пункт настроек билдсервера, никаких проблем.
Почему за ревью код следит система контроля версий? Почему она определяет из какой ветки можно собирать релиз, а из какой нельзя?
Намного более правильная схема: выбрали в issue tracker тэг на основании которого собран релиз, issue tracker запросил у fisheye (или аналогичной системы), все ли коммиты имеют ревью, если не все, то релиз выпустить нельзя. И опять-таки, никаких скритов написанных на коленке и удобные интерфейсы.
Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
Почему система контроля версия когда ей говорит «комить» прогоняет тесты?
Этим должен заниматься билд-сервер. На VCS завязан только триггер билдсервера, запускающий прогон тестов. Поменяли систему контроля версий — изменили один пункт настроек билдсервера, никаких проблем.
Почему за ревью код следит система контроля версий? Почему она определяет из какой ветки можно собирать релиз, а из какой нельзя?
Намного более правильная схема: выбрали в issue tracker тэг на основании которого собран релиз, issue tracker запросил у fisheye (или аналогичной системы), все ли коммиты имеют ревью, если не все, то релиз выпустить нельзя. И опять-таки, никаких скритов написанных на коленке и удобные интерфейсы.
Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
Сколько людей — столько мнений, и это хорошо :)
Моё мнение — инфраструктуру проекта надо рассматривать целиком.
Можно набирать её из компонент (cvs,ci, багтрекер) и интегрировать, а можно (разумеется, если есть время-ресурсы) допилить одну из vcs под свои нужды. главное, чтобы всё вместе хорошо работало и было поддерживаемым.
> Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
вы наверное и аннотации не любите :) и инструкции не по сборке, а по менеджменту этого кода — кто может менять, что делать при изменениях, проч.
это как со конфигурацией Spring'a (я джавер) — можно вынести в XML, можно сделать аннотациями в коде. В коде имхо удобнее.
Моё мнение — инфраструктуру проекта надо рассматривать целиком.
Можно набирать её из компонент (cvs,ci, багтрекер) и интегрировать, а можно (разумеется, если есть время-ресурсы) допилить одну из vcs под свои нужды. главное, чтобы всё вместе хорошо работало и было поддерживаемым.
> Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
вы наверное и аннотации не любите :) и инструкции не по сборке, а по менеджменту этого кода — кто может менять, что делать при изменениях, проч.
это как со конфигурацией Spring'a (я джавер) — можно вынести в XML, можно сделать аннотациями в коде. В коде имхо удобнее.
Аннотации имеют непосредственное отношение к коду, а менеджмент — это другой вопрос.
Да, разумеется при достаточном количестве интузиазма и ресурсов можно свернуть с протоптанного пути и сделать по-своему, но рано или поздно все равно придется интегрироваться как минимум в багтреккер, и тогда опять — интузиазм, ресурсы…
оффтопик: использовать спринговые аннотации в коде удобнее до определенного момнета, пока проект не разрастется. Когда нужно работать с десятками модулей и сотнями классов, то спринговые/хибернейтовые анотации превращаются в спагетти.
Но в целом к аннотациям я отношусь очень хорошо :)))
Да, разумеется при достаточном количестве интузиазма и ресурсов можно свернуть с протоптанного пути и сделать по-своему, но рано или поздно все равно придется интегрироваться как минимум в багтреккер, и тогда опять — интузиазм, ресурсы…
оффтопик: использовать спринговые аннотации в коде удобнее до определенного момнета, пока проект не разрастется. Когда нужно работать с десятками модулей и сотнями классов, то спринговые/хибернейтовые анотации превращаются в спагетти.
Но в целом к аннотациям я отношусь очень хорошо :)))
Я думаю у любого крупного проекта есть такие завязки для облегчения совместной работы. Есть хорошая статья о том как PostgreSQL переходили с CVS на Git — как раз по теме.
CVS + Git
Простите, а почему CVS? С чем связано? Очень контрастно видеть CVS и Git рядом.
Одну использую по правилам компании, вторую изучаю просто для себя и потихоньку применяю. Догадаетесь где какая? :)
Это понятно :) А с чем связано использование CVS в компании? Высокая стоимость смены инфраструктуры (наличие решений по расширению возможностей CVS, определенного ПО, глубокая интеграция & etc.) или какой-то принципиальный момент? Расскажите подробнее!
Сила привычки скорее всего и нежелание геморроиться со старыми репозиториями. Более новые проекты компании уже используют SVN. Особо глубокой интеграции нет.
Я сейчас ещё с gitosis работаю — смотрю можно ли сделать так чтобы я работал с git а какой нибудь скрипт автоматически отправлял мои правки в CVS.
Я сейчас ещё с gitosis работаю — смотрю можно ли сделать так чтобы я работал с git а какой нибудь скрипт автоматически отправлял мои правки в CVS.
SVN+Git+Mercurial :(
SVN (для работы на «дядю») + GIT (для себя)
CVS + MS Team Foundation Server + Git
Основная CVS.
Основная CVS.
Не пользуюсь системами контроля версий.
darcs же.
В DevExpress мы используем собственную систему контроля версий.
я бы постеснялся о таком говорить)
Вот-вот! А вроде солидная компания…
Был вопрос — был ответ :-) Главная же цель опроса — получить общую картину, так зачем мне скрывать?
А так, каждый исходит из своих сценариев работы и из своих задач. Для наших задач нам потребовалось сделать что-то своё, благо были ресурсы и время. И нам это сильно помогает в работе, так что чего тут стесняться?
Будет время, может расскажем об этом поподробнее…
А так, каждый исходит из своих сценариев работы и из своих задач. Для наших задач нам потребовалось сделать что-то своё, благо были ресурсы и время. И нам это сильно помогает в работе, так что чего тут стесняться?
Будет время, может расскажем об этом поподробнее…
видимо у остальных систем есть фатальный недостаток?)
Корпоративно TFS, для своих проектов SVN
SVN + Mercurial
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.
Звучит страшно, но по факту пользоваться удобно, тк за несколько лет было хорошо допилено:
— дешевые бранчи, приемлемый 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» или «slow». Соотсветсвенно есть возможность регулировать компромисс между coverage и временем коммита.
> Как осуществляется выбор того, кто должен проводить ревью кода?
В заголовке файлов есть поля, которые парсятся при коммите.
Поля типа:
— email'ы разработчиков/группы разработчиков, кто может делать code review / approval
— email'ы группы, куда пост-коммит отсылаются diff'ы-уведомления
— Test suites, которые будут запускаться (кроме testsuit'ов по умолчанию)
и проч.
также всё это можно указать в отдельном файле со специальным именем, тогда настройки будут действовать для всех файлов в директории.
Перед коммитом запускаются те, которые не имеют тагов типа «integration»
Существует ситуация когда должен быть заложен код, в результате которых перестают работать тесты. Как я понимаю, вы правите тесты, помечаете их тэгом Integration и закладываете совместно с кодом. Как налажен процесс того, кто потом очистит тэги, что бы тесты не пропускались перед последующими закладками?
В заголовке файлов есть поля, которые парсятся при коммите.
О каких файлах идет речь?
согласен, такие ситуации бывают, но в принципе это уже исключительная ситуация, типа «поменялись требования, тесты менять долго, а функционал нужен сейчас».
в таких случаях тесты помечаются как disabled, т.е. они по-прежнему видны в continuous integration, но не запускаются. А вот их обратное их включение — уже на совести того, кто отключил ;)
> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.
в таких случаях тесты помечаются как disabled, т.е. они по-прежнему видны в continuous integration, но не запускаются. А вот их обратное их включение — уже на совести того, кто отключил ;)
> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.
Гм, нескромный вопрос, а сколько примерно у вас коммитов в неделю, раз у вас получается делать run-tests-before-commit и ревью?
коммитов много (на проекте порядка 80 разработчиков в 10-12 группах). если грубо прикинуть — 1-10 коммитов в день от каждого.
но времени тесты и review занимают немного — писать код всё равно медленнее, чем читать и запускать ;)
но времени тесты и review занимают немного — писать код всё равно медленнее, чем читать и запускать ;)
Ясно. А у нас >5000 коммитов в неделю нормальная ситуация. Ну и прогон тестов от 10 минут и выше. Даже при таких временах велика вероятность получить новую пачку изменений в репозиторий за время прогона тестов перед коммитом.
ну, практически получается задержка в 20-30 секунд перед коммитом — что имхо приемлемо (как раз за это время успеешь ещё раз подумать — всё ли правильно коммитится))
время на ревью — открыть ссылку из почты, просмотреть изменения, нажать кнопочку «согласен» или написать «кг-ам» в комментариях. задержка ревью обычно 5-30 минут.
я не навязываю, просто для нашего проекта-группы это работает. у вас может быть другой проект и другие реалии.
да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.
время на ревью — открыть ссылку из почты, просмотреть изменения, нажать кнопочку «согласен» или написать «кг-ам» в комментариях. задержка ревью обычно 5-30 минут.
я не навязываю, просто для нашего проекта-группы это работает. у вас может быть другой проект и другие реалии.
да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.
А в каждом комите плюс еще операций правок порядка 5-10 (в среднем), так?
нет. обычно без правок, иногда 1-2 правки.
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.
опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.
опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)
mercurial на работе, git для себя.
git+svn
git, git-svn
И под Vs.Net — VisualSVN… Когда уже VisualGit выпустят?
Уже есть Git Extensions ( code.google.com/p/gitextensions/ ) интегрируеться с VS 2005,2008,2010 + Хороший UI для отображения веток и тд.
В нашей организации используется VSS — это пиздецЪ!
А вообще я сторонник GIT и удивлён, что он не лидирует.
А вообще я сторонник GIT и удивлён, что он не лидирует.
svn+git
Mercurial. т. к. распределенный, кросплатформенный, и имеет удобный UI.
На работе ужасный MS-VSS, для своих проектов использую Mercurial
Личные проекты на GIT, корпоративные на SVN.
svn+bzr
В основном SVN, но есть и Mercurial
git+mercurial
SVN + GIT
git, mercurial, svn
TFS
git+svn
хотелось бы только Git, но приходится юзать Git + SVN
Интересно, а есть кто-то, кто еще пользуется AccuRev?
П.С. не понимаю зачем постаить повторяющиеся ответы в виде комментов, когда достаточно нажать +1 или в худшем случае (если нет кармы) как ответ. А то мне кажется что как минимум «git+svn» повторялись несколько раз.
П.С. не понимаю зачем постаить повторяющиеся ответы в виде комментов, когда достаточно нажать +1 или в худшем случае (если нет кармы) как ответ. А то мне кажется что как минимум «git+svn» повторялись несколько раз.
IBM Rational Team Concert. В купе с разработкой под Eclipse неожиданно оказалась много удобнее SVN + Subversive.
SVN, смотрим в сторону Git.
4-летний проект на PHP/Python
4-летний проект на PHP/Python
Теперь этот опрос наверно, будет ежегодной традицией. Можно будет отслеживать тренды. А для какой конференции вы сделали этот опрос? Куда пойдут результаты?
Sign up to leave a comment.
Какие системы управления версиями вы используете? (В реальной работе. Опрос для конференции).