| |
| 2.3, svn (??), 10:17, 21/07/2009 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>В чём преимущества git перед svn
В том что можно улучшать код работая с системой контроля версий, не имея прав на запись в центральный репозиторий.
| | |
| 2.4, anonymous (??), 10:55, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>В чём преимущества git перед svn
нет докачки, ревизии помечаются непонятно чем, невозможность вытащить изменения без создания локальной копии. В общем одни преимущества! :D
| | |
| |
| 3.7, anonymous (??), 11:09, 21/07/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >нет докачки
можно качать тар-болы.
> , ревизии помечаются непонятно чем
А вы хотели, чтобы при децентрализованной модели каждый ваш коммит блочил все репозитории пр всей глобальной сети? Проект большой - нужно распределять - а иначе увеличения производительности не получите - ширина канала конечна, мощность железа тоже.
> , невозможность вытащить изменения без создания локальной копии
А нафига вам изменения без исходников?
Зато есть:
1. нормальные ветки.
2. cherry-pick
3. и так далее.
| | |
| |
| 4.8, Andrew Kolchoogin (?), 11:14, 21/07/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А нафига вам изменения без исходников?
Вас, любезный мой, никогда не просили прислать письмом патчик? Меня вот регулярно просят...
И вообще, что это за Redmond'щина: "Нафига вам?.."
| | |
| |
| 5.13, anonymous (??), 11:50, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Вас, любезный мой, никогда не просили прислать письмом
>патчик? Меня вот регулярно просят...
На kernel.org лежат патчи. Так что получается, что это проблема организации доступа к репозиторию, а не системы контроля версий. Тем кто пишет git патчи не нужны - потому они не заморачивались на ее реализацию. А сам git можно использовать для хранения патчей.
У системы контроля версий другие задачи и требовать от них, чтобы они работали одинаково глупо. Git подтверждение тому, что одну и туже задачу можно решить разными способами.
| | |
| |
| 6.14, anonymous (??), 12:08, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>На kernel.org лежат патчи. Так что получается, что это проблема организации доступа к репозиторию, а не системы контроля версий. Тем кто пишет git патчи не нужны - потому они не заморачивались на ее реализацию. А сам git можно использовать для хранения патчей.
Как раз наоборот, это попытка обойти ограничения гита. Для svn этого вообще не требовалось бы. Но вообще, я не против гита. Пусть переходят. Но мне не нравится, когда это делают попутно закрывая другие способы обновления исходников. Как пример могу привести закрытый rsync и qt-copy. Причём даже снапшоты перестали выкладывать: ftp://ftp.kde.org/pub/kde/unstable/snapshots/ Непонятно, почему этот гит так навязывают.
| | |
| |
| 7.19, BSA (?), 12:44, 21/07/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ты зайди на gitorious.org и посмотри, как ведется разработка тех же qt и qt-creator. Увидишь, что тусуется там куча народа, некоторые объеденены в команды (team). Все кому надо сделали тематические клоны основного репозитория (хранятся на гиториусе). Затем каждый разработчик делает локальный клон у себя на компе. Ведет разработку. Периодически выставляются merge request (запросы на "вливание" кода в основной репозиторий). Пара человек ими управляет (т.е. принимают решение о сливание, доработке или об отказе). В итоге, права на запись в основной репозиторий имеют несколько человек, тогда как изменения вносить может кто угодно (главное, чтобы они были нужными с точки зрения тех, кто имеет права).
На гиториоусе организовано все довольно грамотно (гораздо удобней, чем на kernel.org, когда сначала надо подписаться на mailing-list, попереписываться там неделю другую, чтобы твой патч включили) - зарегистрировался, сгенерировал ssh ключи, добавил их на сайт, клонировал репозиторий в свой аккаунт, клонировал этот клон себе на комп, сделал бранч, внес изменения, запашил в свой клон, запросил merge request с основным репозиторием.
Правда, есть один огромный недостаток - надо иметь семь пядей во лбу, чтобы до всего этого догадаться, так как никакой толком информации нет. А если и есть, то искать надо по всему сайту.
| | |
| |
| |
| 9.30, BSA (?), 22:02, 21/07/2009 [^] [^^] [^^^] [ответить] | +/– | Толстый канал нужен только для clone Все остальные операции меньше требуют траф... текст свёрнут, показать | | |
|
|
|
|
|
| 4.10, anonymous (??), 11:26, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>можно качать тар-болы.
Которые тоже не докачиваются. Малейший обрыв и всё по новой.
>А вы хотели, чтобы при децентрализованной модели каждый ваш коммит блочил все репозитории пр всей глобальной сети? Проект большой - нужно распределять - а иначе увеличения производительности не получите - ширина канала конечна, мощность железа тоже.
Ширина канала для git-а как раз и нужна. Желательно мегабитный и стабильный анлим. Сделать git clone на стандартном 256 кбит/с не представляется возможным не говоря уж про более медленные технологии.
>А нафига вам изменения без исходников?
Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.
>Зато есть:
>1. нормальные ветки.
>2. cherry-pick
>3. и так далее.
Толку мне от их наличия, если у меня и так 2-х мегабитный анлим?
| | |
| |
| 5.27, 1 (??), 14:40, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.
>
>
>>Зато есть:
>>1. нормальные ветки.
>>2. cherry-pick
>>3. и так далее.
>
>Толку мне от их наличия, если у меня и так 2-х мегабитный
>анлим?
Какие-то несостыковочки. Вы определитесь уже какой у вас канал: широкий или не очень.
Агрументация замечательная, тарболы не докачиваются при обрыве. Связи только не вижу между git и тем, что вы не прочитали мануал на wget.
| | |
| |
| 6.32, anonymous (??), 23:04, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Агрументация замечательная, тарболы не докачиваются при обрыве. Связи только не вижу между git и тем, что вы не прочитали мануал на wget.
Вместо сотрясения воздуха своей глупостью предлагаю сходить на гиториус и попробовать.
| | |
|
| |
| |
| 7.35, поцанчик (ok), 15:46, 22/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>через gprs gitorious работает стабильно. Проверял.
>
>До первого обрыва
wget gprs gitorius скачивает/докачивает стабильно только-что проверил. Не гоните чепухи, виндоблядки.
| | |
|
|
| 5.40, anonymous (??), 19:47, 23/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >Ширина канала для git-а как раз и нужна. Желательно мегабитный и стабильный
>анлим. Сделать git clone на стандартном 256 кбит/с не представляется возможным
>не говоря уж про более медленные технологии.
а у меня получалось на моём 128. или ты свистишь, или у тебя руки перманентно к заднице приаттачены.
>Посмотреть изменения, обновить без выкачивания всего и вся, снизить нагрузку на канал.
снизь нагрузку на свой моск, он явно не справляется с работой.
| | |
|
|
|
| 2.5, MaMoHT (?), 10:56, 21/07/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>В чём преимущества git перед svn. Пожет быть и мне пора переходить?
>
Флейм? :-)
Тем, что SVN плохо подходит для того, чтобы вести контроль над большими проектами.
| | |
| |
| 3.6, anonymous (??), 11:03, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>проектами.
Аргументация как всегда на высоте!
| | |
| 3.9, Andrew Kolchoogin (?), 11:15, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Флейм? :-)
> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
> проектами.
FreeBSD -- небольшой проект?
| | |
| |
| 4.11, anonymous (??), 11:29, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Флейм? :-)
>> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>> проектами.
>
> FreeBSD -- небольшой проект?
mandriva вон тоже в svn лежит. И ничего.
| | |
| |
| |
| 6.17, MaMoHT (?), 12:42, 21/07/2009 [^] [^^] [^^^] [ответить] | +/– | Вот же ведь какие прозорливые, заметили же - Забавно, но вот именно git ом я н... большой текст свёрнут, показать | | |
| |
| 7.20, Вова (?), 13:14, 21/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Проблемы, которые испытываем при использовании SVN:
>1. Слияние веток - ну прямо танцы с бубном. В Mercurial делается
>просто на ура.
Какие танцы с бубном? Файл изменяли и в ветке и в транке, конфликт при слиянии в транк - необходимое событие.
>3. Скорость ну просто адская - по локалке 15 метров коммититься полчаса
>- репозиторий при этом для других залочен. Прибегают и спрашивают -
>а что, почему не коммититься? Как это решает mercurial? - просто
>- обработку изменений вы совершаете локально - на сервер надо только
>результат залить.
Ваши локальные проблемы.
>4. Переодически (достаточно часто) отваливается при апдейтах и коммитах.
см. выше.
>5. Последнее время уже не возникало, но были приколы: некоторые умники комитят
>в репозиторий объектники и другие левые файлы. Понавесили хуков, чтобы так
>больше не делали. Но в Mercurial то это проще решается. :-)
Причём здесь свн?
>
>6. Есть проект на Дельфи+Oracle - ну просто старый - но он
>прекрасно справляется с поставленными задачами, потому еще живой. Если кто работатал
>с Дельфи - то должны знать - там ресурсники бинарные -
>надо в репозитории держать. Постоянно вылазят конфликты на этих ресурсниках -
>когда разные люди комитят, при том, что изменений то туда не
>вносится. Ладно, если у вас таких файлов 2-3 - а если
>больше 2-х сотен???
тоже содержим бинарники в свн, если нет изменений, они не заливаются. Фантазии детектед?
| | |
| |
| 8.23, MaMoHT (?), 13:58, 21/07/2009 [^] [^^] [^^^] [ответить] | +1 +/– | Какой файл - Это не один файл - это полсотни файлов - переносить Конфликты S... текст свёрнут, показать | | |
| |
| 9.28, Вова (?), 15:22, 21/07/2009 [^] [^^] [^^^] [ответить] | +/– | По поводу скорости свн user host time svn co http svn ---- trunk trunk c... текст свёрнут, показать | | |
|
| 8.25, MaMoHT (?), 14:09, 21/07/2009 [^] [^^] [^^^] [ответить] | +2 +/– | Пропустил Да, вы правы, это можно решить организационным путем я надеюсь вы пр... текст свёрнут, показать | | |
|
|
|
|
| 4.12, Аноним (-), 11:40, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> FreeBSD -- небольшой проект?
основная разработка до сих пор идет в perforce (в //depot/user и //depot/projects), а не в subversion/svk (в /user и /projects). /head и /stable больше используются для тестирования и интеграции.
Так что да, svn не подходит для больших проектов, и FreeBSD является тому подтверждением.
| | |
| 4.36, поцанчик (ok), 15:47, 22/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Флейм? :-)
>> Тем, что SVN плохо подходит для того, чтобы вести контроль над большими
>> проектами.
>
> FreeBSD -- небольшой проект?
там только одно маленькое ядро. А программы, как известно, они берут отовсюду.
| | |
|
|
| 2.18, Andrey Mitrofanov (?), 12:43, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
Преимущество: KDE уже тоже переходит. Троль, ты отстал. ...и уныл.
http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...
| | |
| |
| 3.21, Вова (?), 13:27, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Преимущество: KDE уже тоже переходит. Троль, ты отстал. ...и уныл.
>http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...
резюмирую: ни с гитом, ни с свн, ни с цвс в жизни ты не работал, так ведь, Андрюш?
| | |
| |
| 4.24, Andrey Mitrofanov (?), 14:02, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>>http:/openforum/vsluhforumID3/56921.html#65 --Дай CVS, дай ложку...
То есть по существу--^^ возражений нет? Записываю: согласился.
>резюмирую:
На здоровье! Не забрызгайте никого.
>ни с гитом, ни с свн, ни с цвс в жизни ты не работал
Форумные анонимы не работают по определению. Они получают удовольствие.
| | |
| |
| 5.38, User294 (ok), 19:10, 22/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Форумные анонимы не работают по определению. Они получают удовольствие.
Они анони... гм... анонимируют :)
| | |
|
|
|
| 2.37, User294 (ok), 19:09, 22/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> В чём преимущества git перед svn. Пожет быть и мне пора переходить?
Как минимум в том что локальный репозиторий - полноценный, с историей изменений и прочая.Так что если что-то гавкнулось на сервере а бэкапов нет или старые - юзеры SVN сосут.Жестоко и хорошо.Юзеры git просто восстанавливают из локальных копий.Кроме того - можно изгаляться над локальной копией как угодно и даже с кем-то поделиться изменениями потом.А на svn все это потребует геморроя по добавлению прав на центральном серваке.В случае git это нафиг не надо.И вообще в ряде случаев можно обойтись без центрального сервака, что иногда ценно.
| | |
|
|
