А вот как у вас модно

[metaclass]

работать с системами контроля версий? Конкретно, с subversion, потому что в меркуриале и прочих DVCS можно хоть обкоммитится до одури - пока в другой репозиторий не закинешь, этого никто не увидит.

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

PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.

Comments

[ex-biespart.livejournal.com]

Я карпарацыйны perforce абгортваю ў git-p4. Для кожнай фічы маю асобную галіну, у якой стэкам складваю ўсе больш-менш сэнсоўныя змены. Перад камітам назад у perforce аб'ядноўваю ўсё напрацаванае ў 1-2 асэнсаваныя каміты (rebase) і тады ўжо раблю git-p4 submit.

[jdevelop.livejournal.com]

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

а если чисто svn - то коммитить в транк всякое говно, в ветку stable это говно потом сливать через тулзу svnmerge, которая костыль для уебанского мержа в свн - но работает

для больших кусков форкнуть бранч, поиздеваться там - и потом взад в транк

[alexott.livejournal.com]

у нас на работе svn, но я пользуюсь git, куда всосал репозиторий через git-svn (можно взять hgsvn, bzr-svn по вкусу). Я тоже предпочитаю коммитить маленькими кусочками - коммит должен содержать одно изменение - исправление ошибки и т.д. Если делается какая-то эксперементальная работа, то я завожу отдельный бранч, работаю в нем, и после того, как все нужное получилось, коммичу в основную ветку разработки и делаю git svn dcommit, так что в центральном репозитории оказываются все сделанные изменения. Но я пользуюсь одним правилом - код в центральном репозитории всегда должен компилироваться и проходить тесты.

[psilogic.livejournal.com]

У нас CVS. Коммит по принципу: если состояние проекта не ухудшится от данного коммита. То есть, нельзя коммитить, например, если от этого проект перестанет собираться.

[dmzlj.livejournal.com]

1) SVN в топку.

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

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

Таким образом, у себя локально - разработчик коммитит как ему удобно часто (с целями бэкапа и отката изменений), в основной девелоперский бранч релиза --- коммитится большими осмысленными аннотированными кусками работы, желательно со ссылкой на соответствующий таск/тикет.

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


UPD. Ответственного за интеграцию можно назначать по-разному: например, сидишь на этой роли как на раздаче на распасах в префе, пока билд не пройдет.

[dmzlj.livejournal.com]

PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.

Суть в том, что авторы CVS и SVN много сделали для того, что бы бранчи воспринимались, как какая-то вещь, с которой надо бороться. На самом деле, это вешь, которая служит для удобства, и бороться там не с чем.

[http://users.livejournal.com/_aive_/]

У нас проекты небольшие, по 3-5 человек, так что только одно правило - после коммита проект должен билдиться :)
А так, если комментарий здравый можешь добавить к коммиту - значит это уже не какая-то мелкая хренотень :)

[aamonster.livejournal.com]

Правильно советуют. Просто чтобы в основной ветке всегда была живая версия.

Вариант (не идеальный, но терпимый) - локальный mercurial + централизованный svn. Коммитить на каждый чих у себя, а как заработает - в svn.

[familom.livejournal.com]

Локально использую mercurial поверх центрального репозитория.

[morozov.livejournal.com]

Что в раньше в SVN, что сейчас в Perforce стараюсь коммитить по возможности как можно чаще. Есть основная ветка разработки, мелкие исправления делаются прямо в ней. Для более крупных заводятся функциональные ветки. Когда работал с SVN, сделали автоматическое развёртывание с созданием метки и переключением на неё копии на боевых серверах.

[zmila.livejournal.com]

мы пользуемся svn. команда из 20 чулавек. коммитается по 100-200 файлов в день. примерно раз в два-три дня пересекамся и приходится решать конфликты. люди наши работают по-разному: кто коммитает небольшие изменения по 1-3 файлам. а кто-то накапливает за несколько дней и потом пуляет сразу десятками.

недавно я с двумя бойцами делали отдельную фичу - создали бранч, и там две недели варились. я замудохался потом объеденять сорцы. но без бранча мы б не смогли. правда я хотел как раз для этого случая заюзать локально hg или git.

[sergiej.livejournal.com]

Для команды больше 10 человек считаю рабочей схему: индивидуальные форки (кто любит каждую стоку коммитить) - транк - ветка для системных тестов - релизная ветка.
Всё что идёт в транк должно компайлится - иначе закомитевшему по голове. Из транка в тест идут те релизы, которые прошли юнит тесты - мержит в тестовую ветку уже тестер. Из тестов в релиз идёт то что прошло тесты. Оперировать довольно просто - девелопер посылает набор номеров релизов, которые должны пойти в тест - тестер замержил - не скомпайлилось - откат. Тестер посылает ответственному за главный билд аналогичный список того, что прошло тесты. Работает как часы даже у раздолбайской команды.