Человеческое лицо subversion - 2

Git очень плохо дружит с proxy. Его можно заставить работать с прокси, но после этого git-svn все равно валится по сигналам после каждой ревизии.

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

Итак, продолжение эксперимента...

Человеческое лицо Subversion

Людям, поработавшим с децентрализованными системами контроля версий, нет необходимости перечислять все вкусности - которые они дают. Но, к сожалению, в сети много проектов, которые используют морально устаревшие централизованные системы контроля. Ладно бы еще subversion, но до сих пор нередко использование cvs.

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

Тащить стабильные ветки - совершенно неинформативно, Весь чейнджлог содержит только собщения о мердже. Следовательно надо тащить к себе транк, который в репозитории FreeBSD традиционно по cvs'овски называется HEAD.

Проблема в том что история FreeBSD - богатая, 200 тысяч ревизий. И как выяснилось, не всякая DVCS долетит до середины репозитория FreeBSD. Решил немного сравнить mercurial и git в этом плане.

Массивные изменения с контролем версий.

Обычно изменения исходников достаточно немногочисленны и разобраться с ними вручную не составляет труда. Но иногда возникают сложности...

Я сейчас строю небольшой дистрибутивчик, встраиваемое решение. Состоит он из ядра linux, busybox и одной программочки из util-linux. Минимум. В оригинале система была построена на базе uClinux, но сделать с ним что-то было весьма не просто, старый, ничего не собирается. Поэтому я его распотрошил, выдернул ядро 2.6.11.8 со всякими патчами как было, взял свежий busybox, свежий util-linux, написал Makefile который все быстро билдит почти с учетом всех зависимостей.

Busybox конечно глючная штука. никак с ним не поборюсь, но основные утилиты работают. Самое страшное для меня - это ядро. Надо отметить, что погружал я его в систему контроля версий почастям... сперва ядро 2.6.11.8, потом hsc0 патч, потом погрузил имеющуюся версию и теперь могу отделить патч от разработчика платы в чистом виде. Кроме того на него уже наложен мой патч на шифрование, но там все просто.

От проекта требуется в первую очередь работать с USB, причем не только как хост, но и как девайс. Вот с этим какраз возникают проблемы, которые заключаются в том, что не все флешки одинаково качественны. И не всякое чтение дойдет до середины флешки.

Это была присказка.. или как говорят - преамбула... теперь наступила амбула.

Поскольку в текущем состоянии все работает, имеет смысл перейти на всежее ядро, предполагаю, что в последних ядрах USB стек сильно отличается от ядра 2.6.11.8, которое выпущено в 2005 году. Если мне не изменяет память USB 2.0 тогда только зародилось.

Делаем бранч, но чтобы не раздувать БД не просто меняем одно ядро на другое, а аккуратно патчим с текущего до последнего. При этом необходимые патчи на архитектуру и на шифрование конечно исчезают, но я их потом аккууратненько наложу. С архитектурой всеравно без напильника не обойтись.

Вот после этого и наступила засада... svn status показывает список изменений, необъятного размера, где часть файлов исчезла, часть файлов появилась, и еще много просто модифицировалось. Надо думать как аккуратно зафиксировать все это. Может быть, пришедшее ко мне в голову решение весьма тривиально, но тем не менее оно достойно того, чтобы взять его на вооружение.

$ svn status | grep \! | sed -e 's/\!//g' | xargs svn rm
$ svn status | grep ? | sed -e 's/\?//g' | xargs svn add
$ svn commit

Первая команда удаляет все исчезнувшие файлы, вторая добавляет все новые. И фиксируем.
Такой вот узелок на память.

Контроль версий с svk...

Не знаю, кто как, но я без контроля версий вообще не могу.

Можно много спорить о том, какие из систем контроля версий лучше.
Но я последнее время пользуюсь SVK. Эта замечательная распределенная система контроля умеет зеркалировать cvs, subversion, perforce... Но даже если сервер зеркалируемой системы контроля недоступен, это не мешает вносить изменения в локальный репозиторий.

Я бы предпочел monotone, но никто из хостеров проектов его пока не поддерживает (хотя может быть уже поддерживает? когда я последний раз этим интересовался?).

Но речь не о том... Недавно, с тех пор, как занялся с упоминаемым ранее армом) у меня возникла необходимость ковыряться в ядре, или того хуже - в uClinux... И вот тут то SVK меня подвел... чтобы загрузить в него проект такого размера (add, commit) нужно несколько часов (если не дней)... Хотя с незначительными изменениями в больших проектах он справляется без особых тормозов.

Его конечно трудно за это винить, он написан на perl... К тому же массовый влив исходников - не самое типичное занятие для системы контроля версий. Но, тем не менее, это вынудимо меня использовать более шуструю систему контроля.

PS: К тому же всеравно, по работе может потребоваться сервер с системой контроля, чего svk не умеет в принципе - он по большей части frontend...