Несколько часов назад разработчики проекта Fedora сообщили (http://lists.fedoraproject.org/pipermail/devel-announce/2010...) о переводе инфраструктуры контроля изменений в spec-файлах и обработки поставляемых в составе пакетов патчей на систему управления исходными текстами Git. В качестве причин выбора Git отмечается высокая скорость обработки запросов, распределенная организация работы, удобные механизмы обработки патчей к upstream коду, привычность системы для разработчиков, поддержка offline режима работы, упрощение внесения экспериментальных изменений и использование Git во многих первичных проектах, таких как Gnome и Linux ядро.
Для автоматизации выполнения типовых для проекта Fedora операций и упрощения миграции на Git для привыкших к CVS разработчиков подготовлена утилита fedpkg, а также комплекс инструментов dist-git (http://fedoraproject.org/wiki/Infrastructure/VersionControl/...), пришедший на смену dist-cvs. Для разделения прав доступа разработчиков ...URL: http://lists.fedoraproject.org/pipermail/devel-announce/2010.../
Новость: http://www.opennet.me/opennews/art.shtml?num=27487
Может кто нибудь сведущий в этой теме, объяснить мне преимущества перехода с CVS на git?
>Может кто нибудь сведущий в этой теме, объяснить мне преимущества перехода с
>CVS на git?прочитайте новость дальше заголовка, хотя бы первый абзац
>>Может кто нибудь сведущий в этой теме, объяснить мне преимущества перехода с
>>CVS на git?
>
>прочитайте новость дальше заголовка, хотя бы первый абзаца причина одна:
We have a very large set of repositories (over 10.5K) and a largish number of
contributors (1050).ну тут как бы да.
Хоть раз попробовав современные Git и Mercurial, или хотя бы SVN, к CVS вернуться совершенно невозможно.
Стошнит.
>преимущества перехода с CVS на git?LoooL! Как Вы вообще, там, без атомарных коммитов, живете?
>Может кто нибудь сведущий в этой теме, объяснить мне преимущества перехода с
>CVS на git?На мой взгляд главная причина -- отсутствие понятия "право коммита"
как такового. Ввиду распределенности системы оно отпадает.
Сделал, закоммитил у себя в бранче, показал. Всё.Остальное см. тут:
http://www.youtube.com/watch?v=4XpnKHJAok8
распределенные репозитории
Молодцы. Теперь вместо одного файла придётся качать все со всей историей изменений. Ура идиотам!
А может это и к лучшему? Меньше "казуалов" будет качать из системы контроля версий, которая не для того создана. По изначальной задумке - система контроля версий это не средство для обслуживания всех качателей свежака а средство взаимодействия РАЗРАБОТЧИКОВ. На всех качателей свежака - никаких серверов не хватит. А вот при РАЗРАБОТКЕ качаться у вас будет только мелкая дельта (в гите это весьма приятно сделано и дельта сливается быстро). А наличие всего репа с всей историей версий - далеко не лишнее, когда что-то где-то отломалось внезапно. Или мало ли - центральный сервак не дай боже сдох. Да, о удобстве тех кто качает 1 раз в жизни и потом забывает о репе навсегда разработчики врядли пекутся. А зачем им это? oOГрубо говоря, CVS сервер-ориентированная модель. А git - равный с равным, в p2p стиле. В CVS можно получить только ошметки от репа. В git - получаешь полноценный реп.
Палишься, анонимный брат. Можно и не качать всю историю . man git-clone, опция --depth
>Палишься, анонимный брат. Можно и не качать всю историю . man git-clone, опция --depthИ что? С этим огрызком хоть полноценно можно работать? Да и нафига мне ВСЕ файлы, когда мне нужны только 5-6.
>И что? С этим огрызком хоть полноценно можно работать? Да и нафига
>мне ВСЕ файлы, когда мне нужны только 5-6.ВСЕ файлы - это spec и патчи. Что конкретно вам из этого нужно?
>ВСЕ файлы - это spec и патчи. Что конкретно вам из этого нужно?Нет, ВСЕ - это все спеки и патчи. А мне нужно выборочное количество спеков/патчей с возможностью коммитить.
>>ВСЕ файлы - это spec и патчи. Что конкретно вам из этого нужно?
>
>Нет, ВСЕ - это все спеки и патчи. А мне нужно выборочное
>количество спеков/патчей с возможностью коммитить.Один пакет (src.rpm) - один репозиторий.
>Один пакет (src.rpm) - один репозиторий.Кошмар!
Гон, какой-то... Участвуешь в разработке приложения, которое тебе как бы нафиг не нужно. А тебе надо взять пару файлов, что-то там попортачить и залить обратно?Интересно, а как ты свой код отлаживать будешь, не имея всех исходных текстов? И кому нужны такие коммиты? Я бы лесом послал такого "коммитера".
Гон...
>И что? С этим огрызком хоть полноценно можно работать?Подождите, в случае SVN ведь все работают с огрызком (локальная копия - без истории версий). И ничего, все как бы довольны. Что за двойные стандарты? oO
Ага, только занимать это будет меньше чем свн-репозиторий.
>Ага, только занимать это будет меньше чем свн-репозиторий.С чего бы это вдруг?
>Меньше "казуалов" будет качать из системы контроля версий, которая не для того создана.Не проще ли тогда вообще закрыть исходники?
А что ты сделал для проекта, что он тебе должен что-то? Ты заплатил? Ты участвуешь в разработке? Нет? Ну тогда иди лесом. Полностью согласен с разрабами.
>А что ты сделал для проекта, что он тебе должен что-то? Ты заплатил? Ты участвуешь в разработке? Нет? Ну тогда иди лесом. Полностью согласен с разрабами.Опять начинается тыканье. Может я разраб, у которого просто физически нет быстрого анлимного интернета. Откуда тебе знать?
Уууу брат... Будь ты разраб то бы знал, что для этого сверх быстрый и сверхбезлимитный инет не нужен. Скачал один раз все целиком, а уж изменения тянуть без разницы под чем, будь то GIT, SVN или вообще BZR. Или плох тот разраб, что не тянет срез каждый раз заново? :)
Ого, кто-то все еще использует (использовал до этого момента) CVS?
>Ого, кто-то все еще использует (использовал до этого момента) CVS?Не только используют, но и новые реализации создают. OpenBSD-шники сейчас пилят OpenCVS http://www.opencvs.org/
>>Ого, кто-то все еще использует (использовал до этого момента) CVS?
>
>Не только используют, но и новые реализации создают. OpenBSD-шники сейчас пилят OpenCVS
>http://www.opencvs.org/Некрофилия :) Почему бы не юзать централизованный Subversion? Кто-нибудь знает хоть один аргумент за CVS, и против SVN?
Не централизованные vs децентрализованные, а именно преимущества отсталого неатомарного CVS?
>>>Ого, кто-то все еще использует (использовал до этого момента) CVS?
>>
>>Не только используют, но и новые реализации создают. OpenBSD-шники сейчас пилят OpenCVS
>>http://www.opencvs.org/
>
>Некрофилия :) Почему бы не юзать централизованный Subversion? Кто-нибудь знает хоть один
>аргумент за CVS, и против SVN?
>Не централизованные vs децентрализованные, а именно преимущества отсталого неатомарного CVS?Нету таких. Вон гентушники стонут, шлют линусу патчи на гит, тестят это на Дроббинсе с его фантой. но пока не очень получается - шибко спецефик. требования
> Кто-нибудь знает хоть один аргумент за CVS, и против SVN?Repo-copy. :)
В CVS'е формат хранения репозитария таков, что может быть легко прочитан человеком. И поэтому плохо обрабатывается машиной. :) Я про отсутствие атомарности мульти-коммитов, конечно.
формат даты в CVS очень хороший - "week ago" и тп; очень удобно, в svn этого нет.
>>>Ого, кто-то все еще использует (использовал до этого момента) CVS?
>>
>>Не только используют, но и новые реализации создают. OpenBSD-шники сейчас пилят OpenCVS
>>http://www.opencvs.org/
>
>Некрофилия :) Почему бы не юзать централизованный Subversion? Кто-нибудь знает хоть один
>аргумент за CVS, и против SVN?
>Не централизованные vs децентрализованные, а именно преимущества отсталого неатомарного CVS?Добавляй еще PostgreSQL в список - собсна не важно какую VCS использовать - главное что-бы процесс был поставлен, а переезд на новую связан с кучей накладных расходов - зачем чинить-то, что не сломано ?
Для нового проекта да - смысл есть, для устоявшегося...