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

[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, которая костыль для уебанского мержа в свн - но работает

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

[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

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

[blacklion.livejournal.com]

Там, собственно, в ядро втянули то, что svnmerge делал снаружи до этого.

[blacklion.livejournal.com]

а вот показать, какие ревизии уже есть в транке, а каких еще нет - оно увы, не сможет, или я не нашел
svn propget svn:merge? :)
Собственно, в 1.6.x механизм svnmege внутри сидит.

[alexott.livejournal.com]

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

[jdevelop.livejournal.com]

а, то есть они взяли и прикрутили svnmerge

ну, костыль конечно, не знал

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

[jdevelop.livejournal.com]

плюс есть svnmerge avail с ключиками -v, очень полезно тоже )

аналог есть?

[psilogic.livejournal.com]

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

[d4s.livejournal.com]

+1

[kurilka.livejournal.com]

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

[vp.livejournal.com]

+1

[alexott.livejournal.com]

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

[dmzlj.livejournal.com]

1) SVN в топку.

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

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

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

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


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

[slonopotamus.livejournal.com]

Я предпочитаю отдельный локальный бранч + rebase -i для вырезания ненужного.

[kurilka.livejournal.com]

У тебя выше dcommit шёл уже после этого действия, т.е. речь про коммит из гитовой разработческой ветки в ветку приаттаченную к свн. Я так понимаю cherrypick?

[slonopotamus.livejournal.com]

> У нас CVS.

Сочувствую.

[psilogic.livejournal.com]

Почему? Оно свою функцию исполняет - и ладно.

[metaclass.livejournal.com]

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

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

[dmzlj.livejournal.com]

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

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

[metaclass.livejournal.com]

Ад оно зловещий. Мне не понравилось, из-за чего я на системы контроля версий забил на несколько лет - до появления гуманного svn :)

[metaclass.livejournal.com]

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