LINUX.ORG.RU

История изменений

Исправление mashina, (текущая версия) :

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

Если только поддерживаешь сдуванием пыли, то может быть этого достаточно, в противном случае не будет постоянно рабочей dev ветки (при этом) с собирающимся транком.

эксперименты с кодом не бывают параллельными,

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

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

Придумываешь себе гемор на ровном месте. Как же тогда быть с бекапами? Код то может долго стабилизироваться и получается тебе нужно бэкапить как сам svn реп, так и свою рабочую копию. C git это всё решается очень просто - { { { временные коммиты в приватную ветку -> push в бэкап(ы) } x N -> rebase } x M -> merge в публичное место }.

Исходная версия mashina, :

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

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

эксперименты с кодом не бывают параллельными,

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

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

Придумываешь себе гемор на ровном месте. Как же тогда быть с бекапами? Код то может долго стабилизироваться и получается тебе нужно бэкапить как сам svn реп, так и свою рабочую копию. C git это всё решается очень просто - { { { временные коммиты в приватную ветку -> push в бэкап(ы) } x N -> rebase } x M -> merge в публичное место }.