Создание веток в SVN — взгляд со стороны.
Nov. 4th, 2009 09:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dememaxСпециально для ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
deterre
Мы возьмем относительно большой репозиторий SVN и посмотрим, как происходит в нём копирование самого большого каталога, насколько изменится размер репозитория после а) копирования этого каталога, б) первого изменения копии каталога и в) второго изменения этой копии.
Действительно ли дело обстоит так, как заявляют разработчики Subversion, и копирование дешевое, а пессимизм Линуса о быстродействии создания копии в SVN в том самом видео не оправдался.
Итак, имеем:
Смотрим на каталог:
Читайте также в моём блоге: про переход с CVS на GIT в Mail.ru и Добавил в дайджест блога '11
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
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-11-04 06:13 pm (UTC)Слушай, а скажи, пожалуйста, а можно ли куски репозитория SVN копировать также как куски репозитория CVS?
Re: можно ли куски репозитория SVN копировать также как к
Date: 2009-11-04 06:18 pm (UTC)А чтоб не запутаться, сами производители в рекомендуют придерживаться определенной структуры.
Re: можно ли куски репозитория SVN копировать также как к
Date: 2009-11-04 06:22 pm (UTC)Re: можно ли куски репозитория SVN копировать также как к
Date: 2009-11-04 06:32 pm (UTC)Это - не знаю, я настолько в этом не разбираюсь в FSFS (ведь репозиторий может быть и в Berkeley DB), но там есть соответствующий инструмент - svnadmin dump.
Хотя мне знающие люди говорили, что грязными руками в FSFS можно залезть и что-то там как следует поменять, не нарушая целостности репозитория.
no subject
Date: 2009-11-04 06:48 pm (UTC)я решил эту проблему путем использования git-svn - центральный репозиторий в svn, там ветки с релизами и т.п., а я все эксперименты провожу у себя, создавая новую ветку на каждый чих. а потом уже коммичу отлаженные куски кода в нужную ветку.
ну и слияние git делает правильней чем svn...
Re: репозиторий засирается, если каждый девелопер будет
Date: 2009-11-04 06:56 pm (UTC)Потом каждый создал для себя личный каталог в branches и переместил соответствующие папки в них.
В результате и ветки не потерялись, и иерархия веток есть.
В общем, как в старом анекдоте, "и не жужжим"!
Насколько я понимаю, в git'е можно сделать иерархию веток, но это будет просто через специальное именование, а так - git'овские ветки - суть одноуровневый список.
Re: репозиторий засирается, если каждый девелопер будет
Date: 2009-11-04 07:00 pm (UTC)Re: репозиторий засирается, если каждый девелопер будет
From:Re: репозиторий засирается, если каждый девелопер будет
From:Re: насчет оффлайновой работы - есть svk
From:no subject
Date: 2009-11-04 07:28 pm (UTC)svn://.../some_product/
svn://.../some_product/releases (tags/...) -- метки релизов, как ни назови, что идёт в продакшн
svn://.../some_product/trunk (devel/...) -- текущая разработка
svn://.../some_product/branches -- то, где девелоперы плодят ветки, экспериментальные релизы, прочая
Да, в branches/ будет много барахла. И пусть. Для этого и создано.
Или я не понял Вашей мысли.
no subject
Date: 2009-11-04 07:30 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:"Как художник - художнику..."
Date: 2009-11-04 07:33 pm (UTC)Re: "Как художник - художнику..."
From:мс вижуал сурс сейф
From:Re: мс вижуал сурс сейф
From:git-svn на моём компе (Gentoo)
Date: 2009-11-04 08:17 pm (UTC)Недавно напоролся, собирая Sun VirtualBox, что если отключен qt, то гуй для него не собирается.
Зато научился виртуальные машины из командной строки конфигурить, красноглазик... :-)
no subject
Date: 2009-11-04 07:12 pm (UTC)но для меня дело вкуса
О вкусах - не спорят.
Date: 2009-11-04 07:24 pm (UTC)Думаю, надо будет написать отдельным постом про этот момент.
Ведь ещё очень важно, какая команда и какие подходы к совместной разработке в ней практикуются.
no subject
Date: 2009-11-04 08:34 pm (UTC)1) Во-первых, он сразу говорит, что ему нужна _распределённая_ система. Все остальные он сразу считает гамном. Это уже слегка не очень-то
2) Perforce?… Perforce. Ну да, извините. Да, он, конечно же, лучше, чем CVS.
[Слушатели смеются] Но все равно это по сути CVS.
Перфорс тоже самое, что цвс? Ха.
3) Там дальше, где он говорит сначала про ветки, потом про коммиты.
Так как раз пжалста! Комитить в свою ветку до появления стабильного "проходящего тесты", потом раздавать всем.
4) После второго вопроса из зала пошёл какой-то бред
5) В чём проблема слияния веток в свн я не понял. В цвс понятно. Но в свн. Да, если всё разъехалось в смысле иходников к чертям, то оно по-любому придётся ручками каждое файло проверять.
6) Content Management
Чем тот же svn не устраивает? Те же ицы, вид сбоку. Опять же, если всё в одной ветке, то всё просто. А вот что хотелось бы посмотреть, как отыскивать изменения, которые пришли из другой ветки через пяток мержей.
Вобщем "несогласная я". alexott навёл на юз-кейс (толи перевод, толи в изначальной речи это мутно прозвучало): когда есть оупен-сорс прожект, и хочется вовсю поиграться с функционалом, при этом иметь свои ветки, проч., и комитить в общий колхоз действительно не надо. Вот тут да, надо подумать.
no subject
Date: 2009-11-04 09:04 pm (UTC)no subject
Date: 2009-11-04 09:17 pm (UTC)(no subject)
From:Re: git/mercurial/bzr сливают изменения гораздо лучше чем svn
From:Re: git/mercurial/bzr сливают изменения гораздо лучше чем svn
From:Re: А вам в продакшене дают апгрейдить на свежие версии?
From:(no subject)
From:Re: svn отвратительно сливает код с патчами, которые прош
Date: 2009-11-04 09:27 pm (UTC)Мне показалось, что в плане отслеживания тут svn всё же даёт фору git'у, хоть разработчики и признаются честно, что их там в этом месте пока колбасит, что по-крайней мере благородно (честно признаться на публике).
Re: "несогласная я", Линус про git в гугле...
Date: 2009-11-04 09:21 pm (UTC)1) Линус известный интриган
2) опять же, исходя их его требований - перфорс можно отнести в один лагерь с тем цвс
3) там, если я правильно понимаю о чём ты, шла речь о другом: в цвс ветвиться = ночной кошмар
4) ноу комментс
5) ты не забывай, что видео датируется маем 2007 года, есть люди, которые до сих пор мучаются с свн версии 1.4, сейчас годовалый свн версии 1.6 - конфетка в плане слияний по сравнению с тем, что мог видеть накануне записи Линус
6) не понял
В плане локальных веток - тут технически действительно другой уровень, "одним кликом" - и без связи с каким-то там сервером у тебя пошли ветки... "другим кликом" - и у тебя всё вернулось или смержелось или ещё там что... насколько я понял, это - затягивает.
Re: "несогласная я", Линус про git в гугле...
Date: 2009-11-04 09:32 pm (UTC)1)
2) Пока мною увиден только один юз-кейс.
3) Так он что с чем меряет? С цвс-ом или с свн-ом?
4)
5) Не, ну в цвс слияние -- это просто адъ. Он там правильно описал процесс с оттягиванием "того самого дня". И с 1.4 я работал себе вполне, кстати. Нормуль. Опять же, повторюсь мёрж не будет простым никогда, кроме "транк не изменился", отбранчевал-поправил-влил обратно в бранч. Всё остальное, конда надо вливать через несколько бранчей, когда конфликты -- бесплатно не будет.Будет тяжело и ручками. Благо, что хоть не с цвс, где с этим просто полный улёт.
6) Всё, что там описывается в слайде Content M-t укладывается легко в svn.
И опять же, он упоминает commit access, а сам-то хитрец, только сам и вливает.
Re: "несогласная я", Линус про git в гугле...
From:Re: "несогласная я", Линус про git в гугле...
From:no subject
Date: 2009-11-05 08:04 am (UTC)Re: мёржить длинные истории "зигзагом" - без проблем с от
Date: 2009-11-07 09:30 am (UTC)Ты бы народу, не работающему с mercurial/git (всё ж таки там это чаще может возникнуть), объяснил бы доходчиво про эту технику и её преимущество, если будет время и желание.
Может, примерчик где наглядный видел, можешь порекомендовать чего.
Re: мёржить длинные истории "зигзагом" - без пробле
From:no subject
Date: 2009-11-07 04:18 am (UTC)Re: умные мужчины писали svn
Date: 2009-11-07 07:55 am (UTC)И в отличие от Линуса, они не позволяют себе подобных выходок, но ведут вполне конструктивный диалог.
У меня сложилось впечатление, что они - предельно откровенны, если их колбасит - то они так и говорят.
При этом ошибочно думать, что GIT законченный и его не колбасит: достаточно почитать в документации к нему про зоопарк понятий staged/cached/indexed, что у новичка напрочь срывает крышу.
Re: умные мужчины писали svn
Date: 2009-11-07 07:59 am (UTC)там как то хорошо отзывались о mercurial и bazaar - типа что он были сделаны по человечески
Re: хорошо отзывались о mercurial и bazaar - типа что он были сде
From:Re: хорошо отзывались о mercurial и bazaar - типа что он были сде
From:Re: люди, которые пописывают ядро Линукса, как то подозр
From:Re: люди, которые пописывают ядро Линукса, как то подозр
From:> вот, что пишет человек, который ядро Линуха пописывае
From:Re: > вот, что пишет человек, который ядро Линуха пописыв
From:Re: > вот, что пишет человек, который ядро Линуха пописыв
From:> если я вас обидел этим суждением
From:Re: умные мужчины писали svn
From:Re: умные мужчины писали svn
From:Re: умные мужчины писали svn
From:Re: умные мужчины писали svn
Date: 2009-11-07 08:20 am (UTC)Re: слушай а какой у тебя емейл?
From: