Проект KDE преодолел важный рубеж в своем развитии - в SVN репозитории проекта зафиксирован (http://www.kdenews.org/2009/07/20/kde-reaches-1000000-commit...) миллионный коммит (http://lists.kde.org/?l=kde-commits&m=124811211002267&w=2). 500-тысячный коммит был совершен 19 января 2006 года, а 750-тысячный спустя 23 месяца - 18 декабря 2007 года. На набор очередных 250 тыс. коммитов потребовалось всего 19 месяцев, что наглядно подчеркивает рост интенсивности развития KDE.
При текущем росте числа разработчиков, Subversion репозиторий уже перестал удовлетворять всем требованиям процесса разработки, потому разработчики проекта планируют в начале следующего года осуществить переход на децентрализованную систему управления исходными текстами Git. В качестве web-фронтэнда и первичного хостинга Git репозитория будет задействован сервис Gitorious (http://gitorious.org/), который также используется (http://qt.gitorious.org/) компанией Nokia при разработке библиотеки ...URL: http://www.kdenews.org/2009/07/20/kde-reaches-1000000-commit...
Новость: http://www.opennet.me/opennews/art.shtml?num=22670
В чём преимущества git перед svn. Пожет быть и мне пора переходить?
>В чём преимущества git перед svnВ том что можно улучшать код работая с системой контроля версий, не имея прав на запись в центральный репозиторий.
>В чём преимущества git перед svnнет докачки, ревизии помечаются непонятно чем, невозможность вытащить изменения без создания локальной копии. В общем одни преимущества! :D
>нет докачкиможно качать тар-болы.
> , ревизии помечаются непонятно чем
А вы хотели, чтобы при децентрализованной модели каждый ваш коммит блочил все репозитории пр всей глобальной сети? Проект большой - нужно распределять - а иначе увеличения производительности не получите - ширина канала конечна, мощность железа тоже.
> , невозможность вытащить изменения без создания локальной копии
А нафига вам изменения без исходников?
Зато есть:
1. нормальные ветки.
2. cherry-pick
3. и так далее.
> А нафига вам изменения без исходников?Вас, любезный мой, никогда не просили прислать письмом патчик? Меня вот регулярно просят...
И вообще, что это за Redmond'щина: "Нафига вам?.."
> Вас, любезный мой, никогда не просили прислать письмом
>патчик? Меня вот регулярно просят...На kernel.org лежат патчи. Так что получается, что это проблема организации доступа к репозиторию, а не системы контроля версий. Тем кто пишет git патчи не нужны - потому они не заморачивались на ее реализацию. А сам git можно использовать для хранения патчей.
У системы контроля версий другие задачи и требовать от них, чтобы они работали одинаково глупо. Git подтверждение тому, что одну и туже задачу можно решить разными способами.
>На kernel.org лежат патчи. Так что получается, что это проблема организации доступа к репозиторию, а не системы контроля версий. Тем кто пишет git патчи не нужны - потому они не заморачивались на ее реализацию. А сам git можно использовать для хранения патчей.Как раз наоборот, это попытка обойти ограничения гита. Для svn этого вообще не требовалось бы. Но вообще, я не против гита. Пусть переходят. Но мне не нравится, когда это делают попутно закрывая другие способы обновления исходников. Как пример могу привести закрытый rsync и qt-copy. Причём даже снапшоты перестали выкладывать: ftp://ftp.kde.org/pub/kde/unstable/snapshots/ Непонятно, почему этот гит так навязывают.
А ты зайди на gitorious.org и посмотри, как ведется разработка тех же qt и qt-creator. Увидишь, что тусуется там куча народа, некоторые объеденены в команды (team). Все кому надо сделали тематические клоны основного репозитория (хранятся на гиториусе). Затем каждый разработчик делает локальный клон у себя на компе. Ведет разработку. Периодически выставляются merge request (запросы на "вливание" кода в основной репозиторий). Пара человек ими управляет (т.е. принимают решение о сливание, доработке или об отказе). В итоге, права на запись в основной репозиторий имеют несколько человек, тогда как изменения вносить может кто угодно (главное, чтобы они были нужными с точки зрения тех, кто имеет права).
На гиториоусе организовано все довольно грамотно (гораздо удобней, чем на kernel.org, когда сначала надо подписаться на mailing-list, попереписываться там неделю другую, чтобы твой патч включили) - зарегистрировался, сгенерировал ssh ключи, добавил их на сайт, клонировал репозиторий в свой аккаунт, клонировал этот клон себе на комп, сделал бранч, внес изменения, запашил в свой клон, запросил merge request с основным репозиторием.
Правда, есть один огромный недостаток - надо иметь семь пядей во лбу, чтобы до всего этого догадаться, так как никакой толком информации нет. А если и есть, то искать надо по всему сайту.
>А ты зайди на gitorious.org и посмотри, как ведется разработка тех же qt и qt-creator.И что? Проблемы гита это не отменяет. Разработчик kde/qt обязан иметь стабильный мегабитный анлим. Хуже того, что и для написания программы с использованием этих библиотек требования аналогичные. К слову сказать, для svn up/co хватает даже gprs. Не говоря уж про rsync
Толстый канал нужен только для clone. Все остальные операции меньше требуют трафика (если не ошибаюсь, он к тому же еще жмется). Кстати, SVN тоже самое. Ну разве что, у SVN можно выгрузить только тот кусок, который нужен... Хотя, как отлаживать изменения тогда?
>Толстый канал нужен только для clone.И не только. pull этим тоже страдает.
>Кстати, SVN тоже самое.
свн умеет докачку и не удаляет результаты своей работы в случае обрыва. Простой svn up позволяет спокойно продолжить оборванный checkout
>Ну разве что, у SVN можно выгрузить только тот кусок, который нужен... Хотя, как отлаживать изменения тогда?
Для модульных проектов это дополнительное преимущество.
>Для модульных проектов это дополнительное преимущество.ты так и не удосужился почитать доку по git? а там есть такая штука, как "поддеревья".
git format-patch
git apply-mailbox
?
>можно качать тар-болы.Которые тоже не докачиваются. Малейший обрыв и всё по новой.
>А вы хотели, чтобы при децентрализованной модели каждый ваш коммит блочил все репозитории пр всей глобальной сети? Проект большой - нужно распределять - а иначе увеличения производительности не получите - ширина канала конечна, мощность железа тоже.
Ширина канала для git-а как раз и нужна. Желательно мегабитный и стабильный анлим. Сделать git clone на стандартном 256 кбит/с не представляется возможным не говоря уж про более медленные технологии.
>А нафига вам изменения без исходников?
Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.
>Зато есть:
>1. нормальные ветки.
>2. cherry-pick
>3. и так далее.Толку мне от их наличия, если у меня и так 2-х мегабитный анлим?
>[оверквотинг удален]
>Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.
>
>
>>Зато есть:
>>1. нормальные ветки.
>>2. cherry-pick
>>3. и так далее.
>
>Толку мне от их наличия, если у меня и так 2-х мегабитный
>анлим?Какие-то несостыковочки. Вы определитесь уже какой у вас канал: широкий или не очень.
Агрументация замечательная, тарболы не докачиваются при обрыве. Связи только не вижу между git и тем, что вы не прочитали мануал на wget.
>Агрументация замечательная, тарболы не докачиваются при обрыве. Связи только не вижу между git и тем, что вы не прочитали мануал на wget.Вместо сотрясения воздуха своей глупостью предлагаю сходить на гиториус и попробовать.
через gprs gitorious работает стабильно. Проверял.
>через gprs gitorious работает стабильно. Проверял.До первого обрыва
>>через gprs gitorious работает стабильно. Проверял.
>
>До первого обрываwget gprs gitorius скачивает/докачивает стабильно только-что проверил. Не гоните чепухи, виндоблядки.
>Ширина канала для git-а как раз и нужна. Желательно мегабитный и стабильный
>анлим. Сделать git clone на стандартном 256 кбит/с не представляется возможным
>не говоря уж про более медленные технологии.а у меня получалось на моём 128. или ты свистишь, или у тебя руки перманентно к заднице приаттачены.
>Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.снизь нагрузку на свой моск, он явно не справляется с работой.
>В чём преимущества git перед svn. Пожет быть и мне пора переходить?
>Флейм? :-)
Тем, что SVN плохо подходит для того, чтобы вести контроль над большими проектами.
>Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>проектами.Аргументация как всегда на высоте!
> Флейм? :-)
> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
> проектами.FreeBSD -- небольшой проект?
>> Флейм? :-)
>> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>> проектами.
>
> FreeBSD -- небольшой проект?mandriva вон тоже в svn лежит. И ничего.
Этот мамонт в предыдущей ветке про этот миллионный коммит приводил 9 преимуществ гита перед свном, причём тупо перечислял возможности любой системы контроля версий, он вообще ни разу не программист, от таких пылких юношей толку на опеннет - 0.
>Этот мамонт в предыдущей ветке про этот миллионный коммит приводил 9 преимуществ
>гита перед свном, причём тупо перечислял возможности любой системы контроля версий,
>он вообще ни разу не программист, от таких пылких юношей толку
>на опеннет - 0.
>
>http://www.opennet.me/opennews/art.shtml?num=22603Вот же ведь какие прозорливые, заметили же :-)
Забавно, но вот именно git'ом я не пользуюсь (щас налетят :-) ). Пользую SVN + Mercurial. Админю репозитории исходных кодов (SVN + Mercurial) у себя в конторе.
Проблемы, которые испытываем при использовании SVN:
1. Слияние веток - ну прямо танцы с бубном. В Mercurial делается просто на ура.
2. Как причина предыдущего пункта - ну просто дофига конфликтов возникает. Как вариант - делаем SVN репозиторий общий - а локально Mercurial - ну очень сильно жизнь упрощает.
3. Скорость ну просто адская - по локалке 15 метров коммититься полчаса - репозиторий при этом для других залочен. Прибегают и спрашивают - а что, почему не коммититься? Как это решает mercurial? - просто - обработку изменений вы совершаете локально - на сервер надо только результат залить.
4. Переодически (достаточно часто) отваливается при апдейтах и коммитах.
5. Последнее время уже не возникало, но были приколы: некоторые умники комитят в репозиторий объектники и другие левые файлы. Понавесили хуков, чтобы так больше не делали. Но в Mercurial то это проще решается. :-)
6. Есть проект на Дельфи+Oracle - ну просто старый - но он прекрасно справляется с поставленными задачами, потому еще живой. Если кто работатал с Дельфи - то должны знать - там ресурсники бинарные - надо в репозитории держать. Постоянно вылазят конфликты на этих ресурсниках - когда разные люди комитят, при том, что изменений то туда не вносится. Ладно, если у вас таких файлов 2-3 - а если больше 2-х сотен???
7. Ну и так далее.Системы типа git, mercurial и bazaar удобны хотя бы потому что сервер не нужен. Можно вести контроль версий просто локально для своих внутренних нужд. Было такое дело - поднимали на машине SVN сервер, чтобы свой небольшой проектик вести. :-)))
Почему все еще на SVN. Потихоньку от него уходим - без авралов - а постепенно, кому нужны свистоплятки.
Было забавно - когда написал - можно редактировать историю изменений - сразу налетели - для системы контроля версия типо минус. Смешные. А зачем в SVN svndumpfilter сделали??? :-)))
>Проблемы, которые испытываем при использовании SVN:
>1. Слияние веток - ну прямо танцы с бубном. В Mercurial делается
>просто на ура.Какие танцы с бубном? Файл изменяли и в ветке и в транке, конфликт при слиянии в транк - необходимое событие.
>3. Скорость ну просто адская - по локалке 15 метров коммититься полчаса
>- репозиторий при этом для других залочен. Прибегают и спрашивают -
>а что, почему не коммититься? Как это решает mercurial? - просто
>- обработку изменений вы совершаете локально - на сервер надо только
>результат залить.Ваши локальные проблемы.
>4. Переодически (достаточно часто) отваливается при апдейтах и коммитах.см. выше.
>5. Последнее время уже не возникало, но были приколы: некоторые умники комитят
>в репозиторий объектники и другие левые файлы. Понавесили хуков, чтобы так
>больше не делали. Но в Mercurial то это проще решается. :-)Причём здесь свн?
>
>6. Есть проект на Дельфи+Oracle - ну просто старый - но он
>прекрасно справляется с поставленными задачами, потому еще живой. Если кто работатал
>с Дельфи - то должны знать - там ресурсники бинарные -
>надо в репозитории держать. Постоянно вылазят конфликты на этих ресурсниках -
>когда разные люди комитят, при том, что изменений то туда не
>вносится. Ладно, если у вас таких файлов 2-3 - а если
>больше 2-х сотен???тоже содержим бинарники в свн, если нет изменений, они не заливаются. Фантазии детектед?
> Какие танцы с бубном? Файл изменяли и в ветке и в
>транке, конфликт при слиянии в транк - необходимое событие.Какой файл? :-) Это не один файл - это полсотни файлов - переносить. Конфликты SVN очень плохо разруливает. Детектит их даже там, где их собственно нет. Mercurial это значительно проще все разруливает.
> Ваши локальные проблемы.
Почему только у него? Ведь всё остальное работает на ура. Такие проблемы возникают не только у нас, некоторые просто мирятся с этим (и правда последнее время перестали замечать - если с другим не сравнивают). Многие просто не замечают, потому что SVN очень часто используется для мелких проектов, а то как он ведет себя на крупных мало кого интересует.
Mercurial на том же самом делает это за несколько секунд. Резонный вопрос - почему? Физические условия остаются одинаковыми - даже сервер тот же самый.
> см. выше.
Посмотрел.
> тоже содержим бинарники в свн, если нет изменений, они не заливаются. Фантазии детектед?
Фантазируйте дальше. :-) Если не работали с подобным - то не выдавайте свои домыслы за истину. В ресурснике дельфей много чего хранится и он меняется даже тогда, когда его содержимое на результат не влияет.
Флейм не интересен.
По поводу скорости свн:user@host ~ # time svn co http://svn/----/trunk trunk.copy >log 2>err
real 3m42.218suser 0m18.893s
sys 0m6.824s
user@host ~ # du -sh trunk.copy/
950M trunk.copy/
user@host ~ #
резюме: у нас, в остутствии каких-либо оптимизаций почти гиг чекаутится менее чем 4 минуты.Почему у вас 15 метров льётся годами - это лично Ваши проблемы.
Потом, по поводу бинарных файлов. Изначально утверждалось, что свн не умеет хранить их ревизии. Это неправда. Потом вы утверждали, что заливаются неизменённые файлы. Это тоже не так. Теперь вы утверждаете, что файлы всё-таки изменились, но вы их заливать не хотите. Это опять таки лично ваши проблемы.
Причём здесь гит - не понимаю.
>
>>5. Последнее время уже не возникало, но были приколы: некоторые умники комитят
>>в репозиторий объектники и другие левые файлы. Понавесили хуков, чтобы так
>>больше не делали. Но в Mercurial то это проще решается. :-)
>
> Причём здесь свн?Пропустил. Да, вы правы, это можно решить организационным путем (я надеюсь вы про это?). НО, всегда приходят новички, новички иногда косячат. И в конечном счете - это же приятно, когда такая мелочь решается инструментом, а не "пинками".
Система контроля версий - это бесконечный Ctrl-Z (undo) до самого начала и перенос изменений из одного места в другое. А потом еще и поделится своим трудом. Git, mercurial, bazaar очень хорошо решают эту задачу, SVN тоже хорошо решает - но там упор сделан на другое место - не на работу с исходниками, а чтобы исходники были в одном месте и доступны всем. По-моему этот подход устарел со времен CVS, SourceSafe (а таким убожеством вы не пользовались? если нет - то вам повезло).
Ладно, флейм-флеймом - а надоело уже.
У меня сынишка растет, от общения с ним я понял, что поддерживать разговор можно двумя словами - "зачем" и "почему". Ему простительно - он учится общаться. А как вам, отвечать на вопросы: "причем здесь" , "ваши проблемы", "фантазируете дальше" и так далее???
Это был риторический вопрос - ответ не ожидается. В ветку больше не захожу - не интересно.
> FreeBSD -- небольшой проект?основная разработка до сих пор идет в perforce (в //depot/user и //depot/projects), а не в subversion/svk (в /user и /projects). /head и /stable больше используются для тестирования и интеграции.
Так что да, svn не подходит для больших проектов, и FreeBSD является тому подтверждением.
>> Флейм? :-)
>> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>> проектами.
>
> FreeBSD -- небольшой проект?там только одно маленькое ядро. А программы, как известно, они берут отовсюду.
http://www.youtube.com/watch?v=4XpnKHJAok8
Преимущество: KDE уже тоже переходит. Троль, ты отстал. ...и уныл.
http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...
>Преимущество: KDE уже тоже переходит. Троль, ты отстал. ...и уныл.
>http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...резюмирую: ни с гитом, ни с свн, ни с цвс в жизни ты не работал, так ведь, Андрюш?
>>http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...То есть по существу--^^ возражений нет? Записываю: согласился.
>резюмирую:
На здоровье! Не забрызгайте никого.
>ни с гитом, ни с свн, ни с цвс в жизни ты не работал
Форумные анонимы не работают по определению. Они получают удовольствие.
>Форумные анонимы не работают по определению. Они получают удовольствие.Они анони... гм... анонимируют :)
> В чём преимущества git перед svn. Пожет быть и мне пора переходить?Как минимум в том что локальный репозиторий - полноценный, с историей изменений и прочая.Так что если что-то гавкнулось на сервере а бэкапов нет или старые - юзеры SVN сосут.Жестоко и хорошо.Юзеры git просто восстанавливают из локальных копий.Кроме того - можно изгаляться над локальной копией как угодно и даже с кем-то поделиться изменениями потом.А на svn все это потребует геморроя по добавлению прав на центральном серваке.В случае git это нафиг не надо.И вообще в ряде случаев можно обойтись без центрального сервака, что иногда ценно.