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

[metaclass]

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

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

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

Comments

[ex-biespart.livejournal.com]

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

[morozov.livejournal.com]

А есть где-то руководство для чайников по поводу настройки git-p4 под виндовс? Насколько я понимаю, из коробки (как git-svn) такое не работает. Очень хотелось бы попробовать.

[ex-biespart.livejournal.com]

Тут ничего не подскажу - я очень далёк от Windows. Но, в принципе, git-p4 - это обычный python-скрипт без больших внешних зависимостей, который вызывает p4 из $PATH. Не вижу причин, по которым он не будет работать под Windows.
Естественно, прийдётся немного больше попотеть, настраивая окружение...

[jdevelop.livejournal.com]

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

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

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

[kurilka.livejournal.com]

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

[blacklion.livejournal.com]

Не нужен в svn костыль уже, 1.6.x вполне хорошо нативно мерджит.

[lionet.livejournal.com]

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

Легче уж бранчи с номерами ревизий в имени делать.

[jdevelop.livejournal.com]

если ты про --reintegrate, тогда оно как бы и да, бранч целиком засосет за милую душу

а вот показать, какие ревизии уже есть в транке, а каких еще нет - оно увы, не сможет, или я не нашел

например такое действие

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

как это просто сделать в svn - я не знаю, но вот

svnmerge merge -r 1,3,4,11,25

работает отлично

[alexott.livejournal.com]

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

[d4s.livejournal.com]

+1

[kurilka.livejournal.com]

Cлушай, а как у тебя выглядит "коммичу в основную ветку разработки"? Через cherrypick?

[alexott.livejournal.com]

зависит от того, что за ветка - если это trunk, то туда уходит все из master через dcommit. если ветка - отдельный бранч в svn, типа для фиксения ошибок в конкретной версии, то да - использую cherrypick

[vp.livejournal.com]

+1

[psilogic.livejournal.com]

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

[slonopotamus.livejournal.com]

> У нас CVS.

Сочувствую.

[dmzlj.livejournal.com]

1) SVN в топку.

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

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

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

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


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

[metaclass.livejournal.com]

Насчет "коммитится большими осмысленными аннотированными кусками работы, желательно со ссылкой на соответствующий таск/тикет." - это в DVCS есть методы "объединить over 9000 коммитов из одной локальной репы в один коммит в основную"?

Кстати, разделить релизный и центральный реп для бэкапов - до этого я не додумался с hg, это хорошая идея. Не додумался, потому как в svn у нас центральный и релизный это общий реп на сервере.

[dmzlj.livejournal.com]

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

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

[metaclass.livejournal.com]

Я как-то опасаюсь, что у меня в результате работы в бранчах репозиторий превратится в рандомный граф из ченджесетов и ревизий и я сойду с ума читать логи изменений в случае чего.
Т.е. c 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 человек считаю рабочей схему: индивидуальные форки (кто любит каждую стоку коммитить) - транк - ветка для системных тестов - релизная ветка.
Всё что идёт в транк должно компайлится - иначе закомитевшему по голове. Из транка в тест идут те релизы, которые прошли юнит тесты - мержит в тестовую ветку уже тестер. Из тестов в релиз идёт то что прошло тесты. Оперировать довольно просто - девелопер посылает набор номеров релизов, которые должны пойти в тест - тестер замержил - не скомпайлилось - откат. Тестер посылает ответственному за главный билд аналогичный список того, что прошло тесты. Работает как часы даже у раздолбайской команды.