Создание веток в SVN — взгляд со стороны.

[dememax]

Специально для deterre

Мы возьмем относительно большой репозиторий SVN и посмотрим, как происходит в нём копирование самого большого каталога, насколько изменится размер репозитория после а) копирования этого каталога, б) первого изменения копии каталога и в) второго изменения этой копии.

Действительно ли дело обстоит так, как заявляют разработчики Subversion, и копирование дешевое, а пессимизм Линуса о быстродействии создания копии в SVN в том самом видео не оправдался.

Итак, имеем:

• usr@hst $ uname -a
  Linux hst 2.6.27.29-0.1-xen #1 SMP 2009-08-15 17:53:59 +0200 i686 i686 i386 GNU/Linux

  при этом как бы два ядра Intel(R) Xeon(R) CPU E5205 @ 1.86GHz, памяти 2G
• Современную версию SVN: 1.6.3, r38063, compiled Jul 10 2009 (в соответствии с принятым графиком выпуска релизов, 1.7 должна выйти в начале следующего года)
• Репозиторий в SVN в формате FSFS, общим объемом 7.4G на диске, с количеством ревизий около 230 тысяч
• Каталог в этом репозитории, последняя версия которого занимает 1.8G на диске (если удалить все папки «.svn»), файлы могут иметь и 100 ревизий, и больше.
• Работаем локально, используя протокол «file:/»
• Некоторые имена в листингах изменены для конспирации, но не цифры

Исходное состояние

Смотрим на репозиторий:

usr@hst $ du -s -h /home/devel/some/svn
7.4G    /home/devel/some/svn
usr@hst $ du -s -b /home/devel/some/svn
6394885893      /home/devel/some/svn
usr@hst $ find /home/devel/some/svn -type d | wc
    469     469   16142
usr@hst $ find /home/devel/some/svn -type f | wc
 459058  459058 18838117
usr@hst $

Смотрим на каталог:

usr@hst:~/tmp $ svn co file:///home/devel/some/svn/project/trunk
usr@hst:~/tmp $ find trunk -type d -name .svn -exec rm -r -f {} \;
usr@hst:~/tmp $ du -s -h trunk
1.8G    trunk
usr@hst:~/tmp $ du -s -b trunk
1723226369      trunk
usr@hst:~/tmp $ find trunk -type d | wc
   3609    3609  157100
usr@hst:~/tmp $ find trunk -type f | wc
  59815   59844 3184332
usr@hst:~/tmp $

Копирование

Теперь осуществляем копирование:

usr@hst:~/tmp $ `which time` svn cp -m "SVN copy test." file:///home/devel/some/svn/project/trunk file:///home/devel/some/svn/branches/copytest

Committed revision 229516.
0.01user 0.00system 0:00.20elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
56inputs+152outputs (0major+1008minor)pagefaults 0swaps
usr@hst:~/tmp $

Недурно. Практически сразу. «ч.т.д.»

Состояние репозитория

И как же изменился репозиторий в цифрах:

usr@hst $ du -s -b /home/devel/some/svn
6394886868      /home/devel/some/svn
usr@hst $ find /home/devel/some/svn -type d | wc
    469     469   16142
usr@hst $ find /home/devel/some/svn -type f | wc
 459060  459060 18838201
usr@hst $

Вырос всего на 975 байт, каталогов столько же, файлов стало на два больше. Т.е. и по времени быстро, да и по размеру — изменений совсем мало. Очевидно, копия не реальная, а лишь «пометка».

Первое изменение копии

Ну, хорошо, а что же произойдет, если изменить в копии файлик, который к тому же лежит глубоко?

usr@hst:~/tmp $ `which time` svn co file:///home/devel/some/svn/branches/copytest/one/two/three
A    three/firstfile
  ....
A    three/lastfile
 U   three
Checked out revision 229516.
0.03user 0.00system 0:01.14elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
1104inputs+1232outputs (0major+1140minor)pagefaults 0swaps
usr@hst:~/tmp $ cd three
usr@hst:~/tmp/three $ echo "/*** Just to test copy on write ***/" >> somefile
usr@hst:~/tmp/three $ `which time` svn ci -m "Just to test copy on write."
Sending        somefile
Transmitting file data .
Committed revision 229517.
0.00user 0.01system 0:01.09elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
184inputs+472outputs (0major+1274minor)pagefaults 0swaps
usr@hst:~/tmp/three $

Первое изменение копии прошло без особого напряжения.

Состояние репозитория

Как теперь выглядит репозиторий со стороны?

usr@hst $ du -s -b /home/devel/some/svn
6394900305      /home/devel/some/svn
usr@hst $ find /home/devel/some/svn -type d | wc
    469     469   16142
usr@hst $ find /home/devel/some/svn -type f | wc
 459062  459062 18838285
usr@hst $

Это уже что-то — 13437 байт прибавилось и опять два файлика.

Второе изменение копии

Напоследок, ещё одно изменение в другом каталоге на том же уровне вложенности:

usr@hst:~/tmp $ `which time` svn co file:///home/devel/some/svn/branches/copytest/one/two/four
A    four/firstfile
  ....
A    four/lastfile
 U    four
Checked out revision 229517.
0.01user 0.00system 0:00.44elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
368inputs+416outputs (0major+1085minor)pagefaults 0swaps
usr@hst:~/tmp $ cd four
usr@hst:~/tmp/four $ echo "/*** Just to test copy on write ***/" >> somefile
usr@hst:~/tmp/four $ `which time` svn ci -m "Just to test copy on write. Second commit."
Sending        somefile
Transmitting file data .
Committed revision 229518.
0.01user 0.01system 0:00.86elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
80inputs+384outputs (0major+1219minor)pagefaults 0swaps
usr@hst:~/tmp/four $

Состояние репозитория

Репозиторий:

usr@hst $ du -s -b /home/devel/some/svn
6394911759      /home/devel/some/svn
usr@hst $ find /home/devel/some/svn -type d | wc
    469     469   16142
usr@hst $ find /home/devel/some/svn -type f | wc
 459064  459064 18838369
usr@hst $

Увеличение на 11454 байта, меньше, чем для первого изменения, и те же два файлика.

Итоги

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

Состояние репозитория	Размер строки комментария к изменению, символов	Размер изменений в файле, символов	Количество файлов репозитория, шт.	Размер репозитория, байт	Разница с предыдущим состоянием, байт
Исходное состояние	-	-	459058	6394885893	-
С копией	14	-	459060	6394886868	+975
После первого изменения в копии	27	26	459062	6394900305	+13437
После второго изменения в копии	42	26	459064	6394911759	+11454

Читайте также в моём блоге: про переход с CVS на GIT в Mail.ru и Добавил в дайджест блога '11

Comments

[itman.livejournal.com]

Ты знаешь, что после того, что мне рассказали про ветки в CVS (я каким-то чудом умудрился не наступить на эти грабли), я пришел к выводу, что SVN - это все-таки правильная штука. Правда у нас с ней периодически возникают локальные геморрои. То там народ ссылки поставит, и svn up на каталог выше не работает, то авторизацию через ж сделают, так что нужно каждый день авторизоваться. Но так, вообще, ничего, шустро.
Слушай, а скажи, пожалуйста, а можно ли куски репозитория SVN копировать также как куски репозитория CVS?

Re: можно ли куски репозитория SVN копировать также как к

[dememax]

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

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

Re: можно ли куски репозитория SVN копировать также как к

[itman.livejournal.com]

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

Re: можно ли куски репозитория SVN копировать также как к

[dememax]

А, понял!
Это - не знаю, я настолько в этом не разбираюсь в FSFS (ведь репозиторий может быть и в Berkeley DB), но там есть соответствующий инструмент - svnadmin dump.
Хотя мне знающие люди говорили, что грязными руками в FSFS можно залезть и что-то там как следует поменять, не нарушая целостности репозитория.

[alexott.livejournal.com]

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

Re: репозиторий засирается, если каждый девелопер будет

[dememax]

Мы сначала клали каждый свои ветки отдельным каталогом в branches.

Потом каждый создал для себя личный каталог в branches и переместил соответствующие папки в них.
В результате и ветки не потерялись, и иерархия веток есть.
В общем, как в старом анекдоте, "и не жужжим"!

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

Re: репозиторий засирается, если каждый девелопер будет

[alexott.livejournal.com]

а зачем мне в гите иерархия веток? кроме меня их все равно никто не видит

Re: репозиторий засирается, если каждый девелопер будет

[dememax]

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

Ещё, чем по определению не может похвастаться svn - это off-line'овой работой, конечно.

[ex-sanaris.livejournal.com]

git & mercurial как-то больше доставляют если честно.
но для меня дело вкуса

О вкусах - не спорят.

[dememax]

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

Re: репозиторий засирается, если каждый девелопер будет

[alexott.livejournal.com]

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

насчет оффлайновой работы - есть svk, который делает тебе персональный svn сервер

[rezdm.livejournal.com]

В смысле "засирается"?

svn://.../some_product/
svn://.../some_product/releases (tags/...) -- метки релизов, как ни назови, что идёт в продакшн
svn://.../some_product/trunk (devel/...) -- текущая разработка
svn://.../some_product/branches -- то, где девелоперы плодят ветки, экспериментальные релизы, прочая
Да, в branches/ будет много барахла. И пусть. Для этого и создано.

Или я не понял Вашей мысли.

[alexott.livejournal.com]

у меня вполне стандартная практика - 1-3 новых ветки в день, как будет выглядеть каталог branches после пары лет разработки?

Re: насчет оффлайновой работы - есть svk

[dememax]

Да, спасибо за напоминание, это для меня всё время было чем-то ещё далёким от совершенство, надо пересмотреть.

Ещё вспомнил, что промежуточный staged/cached/indexed уровень есть в git; наверно удобно - ещё один уровень готовности изменений иметь, которым можно и не пользоваться.

"Как художник - художнику..."

[dememax]

Дима, а ты пользовался git'ом для реальных проектов?

Re: "Как художник - художнику..."

[rezdm.livejournal.com]

Неа, пока не довелось.
Из моего опыта работы
Perforce, CVS, SVN, MS-чего-то там забыл что на самом деле не MS, собственная надстройка на MS (которая добавляла транзакционность, распределённые репозитарии, т.п.)
Просто смотрел на Rational'овский

Пока из всего опробованного работавшего самым удобным было SVN и Perforce (но у перфорса свои заморчки, из-за которых он не всякой, как мне кажется, разработке подходит)

[rezdm.livejournal.com]

Ааааа, куда пропал мой мессадж.

В таком случае, как опять же было и есть и достаточно удобно:

svn://.../some_product/
svn://.../some_product//releases (tags/...)
svn://.../some_product//trunk (devel/...)
svn://.../some_product//branches

где -- или major или ...

ну и все свои "1-3 новых ветки в день" удачно ложаться и за два года не замусориваются.

При нормальном администрировании с баг-тракинг (таск/...) в последующем также удобно отслеживать/искать/...

мс вижуал сурс сейф

[dememax]

Да, да, помню, причём почти только по Эр-Стайлу.
Для меня это буквально - прошлый век, т.к. с тех пор (а работал я в стуле в прошлом веке) я к нему не возвращался.

Похоже, git и иже с ним - меняют кое-что во взгляде на разработку, точнее, что-то добавляют...

git-svn на моём компе (Gentoo)

[dememax]

Блин, стал смотреть, обнаружил интересную особенность.

dememax@dememax-laptop ~/tmp $ git svn
fatal: git was built without support for git-svn (NO_PERL=YesPlease).
dememax@dememax-laptop ~/tmp $

Ну, у меня действительно отключен перл в USE.

Недавно напоролся, собирая Sun VirtualBox, что если отключен qt, то гуй для него не собирается.
Зато научился виртуальные машины из командной строки конфигурить, красноглазик... :-)

Re: мс вижуал сурс сейф

[rezdm.livejournal.com]

Не, сурс сейф был ещё в Скале, причём там была своя надстройка ещё над ним. Адъская вестчь.

Причём там было так. МС давал гарантию что-то типа до одного гига базы. Утверждалось, что до двух в принципе будет работать. Вобщем, когда я туда пришёл, база была уже под все четыре гига. И даже работало...

[alexott.livejournal.com]

да просто эти ветки сугубо личные - зачем ими загрязнять-то общий репозиторий? просто стиль работы немного отличается для распределенных систем...

[rezdm.livejournal.com]

Упс, там потерялось кой-чего, я использовал запись, которая отпарсилась броузером и получилась гадость.

вот правка:

svn://.../some_product/_version_
svn://.../some_product/_version_/releases (tags/...)
svn://.../some_product/_version_/trunk (devel/...)
svn://.../some_product/_version_/branches

где _version_ -- или major или ...

Что значит сугубо личные? Это работа на дядю или игра в своей песочнице? Видимо я смотрю с другой стороны.


То есть если мысль такова, что есть некий большой оупенсорсный прожект, хочется вносить изменения, "нормально работать", не комитя в публичный svn://.../some_product/_version_/branches/

Ну, может быть. Но в корпоративных разработках не понимаю такого.

[rezdm.livejournal.com]

Макс, почитал я то, что там по ссылке (перевод расшифровки какого-то спича Линуса).

1) Во-первых, он сразу говорит, что ему нужна _распределённая_ система. Все остальные он сразу считает гамном. Это уже слегка не очень-то
2) Perforce?… Perforce. Ну да, извините. Да, он, конечно же, лучше, чем CVS.
[Слушатели смеются] Но все равно это по сути CVS.
Перфорс тоже самое, что цвс? Ха.
3) Там дальше, где он говорит сначала про ветки, потом про коммиты.
Так как раз пжалста! Комитить в свою ветку до появления стабильного "проходящего тесты", потом раздавать всем.
4) После второго вопроса из зала пошёл какой-то бред
5) В чём проблема слияния веток в свн я не понял. В цвс понятно. Но в свн. Да, если всё разъехалось в смысле иходников к чертям, то оно по-любому придётся ручками каждое файло проверять.
6) Content Management
Чем тот же svn не устраивает? Те же ицы, вид сбоку. Опять же, если всё в одной ветке, то всё просто. А вот что хотелось бы посмотреть, как отыскивать изменения, которые пришли из другой ветки через пяток мержей.


Вобщем "несогласная я". alexott навёл на юз-кейс (толи перевод, толи в изначальной речи это мутно прозвучало): когда есть оупен-сорс прожект, и хочется вовсю поиграться с функционалом, при этом иметь свои ветки, проч., и комитить в общий колхоз действительно не надо. Вот тут да, надо подумать.

[alexott.livejournal.com]

для меня это эффективная работа, я коммичу отлаженный код в центральный репозиторий (или если работа длинная, то в отдельную ветку центрального репозитория).
но в личные ветки, я коммичу очень часто - каждые 20-50 строк (обычно это отдельная функция + тест). когда вся функциональность отлажена, закоммичено в центральную ветку... это обычно дневная работа, но центральный репозиторий не получает промежуточные коммиты, совершенно ненужные другим людям (а закоммитить часто нужно, чтобы например, вытащить новый код на другую машину и там протестировать - у меня сейчас 4 разных OS на которых работает софт)

[alexott.livejournal.com]

svn отвратительно сливает код с патчами, которые прошли через несколько веток (я смерджил от кого-то, кто смержил из trunk, потом я поработал, и смержил сам из trunk - получаю проблемы). хоть они и улучшились в последнее время, но все еще есть проблемы...