LINUX.ORG.RU

А так ли хороши распределенные VCS для пользователей?


0

0

При всех новомодных преимуществах распределенных систем контроля версий для разработчиков, я бы отметил один существенный недостаток для пользователей - а это «тысячи» форков.

Уже не первый раз натыкаюсь на то, что для какой-либо библиотеки или программы есть несколько версий от разных товарищей на всяких github-ах и прочих. И мне допустим, чтобы получить свежую версию какой-либо libastral с исправленными ошибками, нужно пройтись по всем pupkin1/astral, zalupkin/megaastral, atkinson/mysuperastral, где каждый исправил по одному разному его любимому багу, и потом собрать это все в кучу для себя.

Проект при этом распыляется и превращается в какого-то неуловимого джо.В отличие от централизованных проектно-ориентированных хостингов (sf, berlios, savannah и т.п.) где я более менее уверен, что скачиваю последнюю версию.

нужно пройтись по всем pupkin1/astral, zalupkin/megaastral, atkinson/mysuperastral, где каждый исправил по одному разному его любимому багу, и потом собрать это все в кучу для себя.

А в централизованных VCS вы бы даже и этого не смогли сделать. Ну разве что искать патчи.

edigaryev ★★★★★
()
Ответ на: комментарий от edigaryev

Я доверяю авторам проекта, поэтому нет особого желания шарится по интернету в поисках форков. К тому же все случаи наличия сторонних патчей, которыми мне приходилось пользоваться, прекрасно ложились на версию x.y.z доступную на основном сайте. В случае джитолюбов, обычно понятия версии не существует.

dr_jumba
() автор топика

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

volh ★★
()

Вот практически живой пример. Есть либа libXYZ, там есть баг b1. Vasya Pupkin вместо отправки патча авторам, исправляет баг и выкладывает vpupkin/libXYZupdated. Потом забывает (забивает) на проект. При этом libXYZ продолжает развиваться (но баг b1 не исправлен) и вот в один прекрасный момент уже нет совместимости с кодом Васи. Васин код нафиг никому не нужен и в основной ветви баг так и не исправлен. Пользователю ibXYZ нужно ломать мозг, чтобы разобраться, что там наделал Вася.

Такие ситуации бывают и с централизованными системами, но вот с ростом git-хостингов, встречаю сейчас более часто.

dr_jumba
() автор топика
Ответ на: комментарий от volh

Это как бы подразумевает, что я должен знать поименно всех Пупкеных, которые понаделали патчей. Это лишняя нагрузка на мозг. Мне нужен конечный продукт, а не поиграться со слиянием форков.

dr_jumba
() автор топика

Это вопрос организации работ. А еще вопрос нубов, освоивших Git и почувствоваших силу в яйцах %)

tailgunner ★★★★★
()

У всех должны быть одинаковые жёны?

ip1981 ☆☆
()

Вообще то тут проблема не в vcs, а проблема в контакте разработчиков, нормальный просто мордой ткнет в свою ветку основного разраба и все. На ланчпаде есть merge request например для этого.

anotheranonymous
()
Ответ на: комментарий от dr_jumba

То есть ты сейчас пытаешься обвинить dvcs в своем ССЗБ? Пользуйся основной веткой. Предлагай туда патчи. И вообще несколько внешних репов в git подключаются элементарно. Подлить или cherry-pick'нуть патч из одного форка в другой еще элементарнее.

anotheranonymous
()
Ответ на: комментарий от tailgunner

> Это вопрос организации работ. А еще вопрос нубов, освоивших Git и почувствоваших силу в яйцах %)

сразу, как только появляется тред об DVCS, вылазит tailgunner и начинает поносить git. к дохтору.

CL-USER
()
Ответ на: комментарий от CL-USER

> сразу, как только появляется тред об DVCS, вылазит tailgunner и начинает поносить git. к дохтору.

Чо ты такой серьезный? %)

tailgunner ★★★★★
()

Вот поэтому давно и говорю, что для проекта с десятком раздолбаев и обезьян оправданы только централизованные VCS. DVCS - это для индивидуальной работы по многим направлениям или для квалифицированной команды.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

ТС говорит про форки вне проекта, а это я могу сделать будь хоть у тебя убожеский CVS. Заведу себе git зеркало и буду там патчить. Но смысл то тот же.

anotheranonymous
()
Ответ на: комментарий от anotheranonymous

То есть ты сейчас пытаешься обвинить dvcs в своем ССЗБ?

Я пытаюсь донести ущербность подхода к dvcs у тех у кого вооброжаемая «сила в яйцах».

И вообще несколько внешних репов в git подключаются элементарно. Подлить или cherry-pick'нуть патч из одного форка в другой еще элементарнее.

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

dr_jumba
() автор топика
Ответ на: комментарий от dr_jumba

> Я пытаюсь донести ущербность подхода к dvcs у тех у кого вооброжаемая «сила в яйцах».

То есть ты тоже понимаешь, что проблема в людях, а не в инструментах?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> tailgunner: Это вопрос организации работ

Совершенно верно. В нормальных проектах, например, в том же git, есть gitworkflows.txt где вся политика объяснена.

tim4dev
()
Ответ на: комментарий от dr_jumba

>Мне бы тарбз какой скачать
Ну и качай, и не сношая мозг себе и другим. Кто тебя заставляет лезть в репозиторий то вообще?!

anotheranonymous
()
Ответ на: комментарий от dr_jumba

>Я пытаюсь донести ущербность подхода к dvcs у тех у кого вооброжаемая «сила в яйцах».

Один неосилятор пытался докать ущербность «функциональных фишек» в питоне, этот феерически расставляет точки над dvcs. Откуда вы беретесь?

Не, я конечно понимаю что это такая инстинктивная защита от перегрузки мозка, но уже даже и не смешно.

volh ★★
()
Ответ на: комментарий от tailgunner

нубы могут освоить разве что hg, git им не по зубам, это же очевидно. сидят потом «ваш гит антигуманен», тьфу.

volh ★★
()
Ответ на: комментарий от volh

> нубы могут освоить разве что hg, git им не по зубам

Глупости. Упертый нуб может тупо заучить команды git, не понимая,нафиг нужны DVCS и как их использовать. Деятельный дурак - самый опасный %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Упертый нуб может тупо заучить команды git

Ты в этом уверен? Нуб ( упертый или нет, не важно ) скорее попытается заучить команды git и гарантированно сфейлит, а потом пойдет искать что-нибудь попросче. Тот же git-log(1) он даже дочитать не сможет, за базаар отвечаю.

volh ★★
()
Ответ на: комментарий от volh

>> Упертый нуб может тупо заучить команды git

Ты в этом уверен?

Да.

попытается заучить команды git и гарантированно сфейлит

Ерунда. Нужно только clone, fetch и commit. Если ты прочитаешь наконец топик, то поймешь, что push они ниасилели %)

Тот же git-log(1) он даже дочитать не сможет

А это и не нужно.

tailgunner ★★★★★
()
Ответ на: комментарий от volh

> Ты в этом уверен? Нуб ( упертый или нет, не важно ) скорее попытается заучить команды git и гарантированно сфейлит, а потом пойдет искать что-нибудь попросче. Тот же git-log(1) он даже дочитать не сможет, за базаар отвечаю.

Нуб выучит как делать коммит, лог, дифф, клон и будет (вполне успешно, кстати) пользовоаться СУВ. Только в случае с гитом велика вероятность, что на каждом углу он будет кричать насколько гит крут (так как это модно).

anonymous
()
Ответ на: комментарий от dr_jumba

> Это как бы подразумевает, что я должен знать поименно всех Пупкеных,

которые понаделали патчей. Это лишняя нагрузка на мозг. Мне нужен

конечный продукт, а не поиграться со слиянием форков.



Ерунда. Если какой-то патч из форка не попал в основной проект, то значит скорей всего нет согласия между автором форка и разработчиками проекта. Т.е. если бы не было git, то в основном репозитории ты имел бы скорей ровно тоже самое и не мучался бы проблемой того, что где-то есть форки с волшебными патчами. Так что, если тебе «нужен конечный продукт», то просто юзай основной репозиторий. А форки они для тех, кто ищет какие-то возможности, которых по каким-то причинам нет или даже не может быть в основном репозитории. По моему всё просто. В чем собственно проблема то?

archimag ★★★
()
Ответ на: комментарий от Kpoxman

>Ничего не мешает юзать DVCS как VCS.

Заметь, я говорил про малодисциплинированное стадо. Им лишнее действие (ты не сможешь же сделать push без commit) будет ломать делать. Будут коммитить локально, набирать ворох изменений, обламываться на пуше в центральный репозиторий, лихорадочно мержить и коммитить без серьёзного тестирования. А потом нормальным участникам проекта разгребать это всё. Даже с SVN умудрялись такого наворотить... :)

KRoN73 ★★★★★
()

Ниасилятор детектед. Или тролль. Как опытный юзер DVCS утверждаю: туфта. В основную ветвь не входит всякая туфта (<very-fat>типа BFS</very-fat>). Зато и нетестированный код в основную ветвь попадает куда реже. А всякие ветки... просто расширена свобода творчества, только и всего

Divius ★★
()
Ответ на: комментарий от volh

> Один неосилятор пытался докать ущербность «функциональных фишек» в питоне, этот феерически расставляет точки над dvcs. Откуда вы беретесь?

школота же

CL-USER
()
Ответ на: комментарий от archimag

Это не работа была, а Just for Fun.

...

А на работе я работаю один и с Mercurial :)

KRoN73 ★★★★★
()

автор не пользовался гитхабом?

а то что патчи не берут в апстрим - это проблема проекта, и стоит задуматься, так ли он вам нужен

// у каждого форка есть кнопочка уведомить автора

yltsrc
()
Ответ на: комментарий от tailgunner

>Ерунда. Нужно только clone, fetch и commit. Если ты прочитаешь наконец топик, то поймешь, что push они ниасилели %)

Ну опять же, освоить git и «нужно только clone, fetch и commit, а push они ниасилели» как-то не стыкуется.

volh ★★
()
Ответ на: комментарий от anonymous

>Только в случае с гитом велика вероятность, что на каждом углу он будет кричать насколько гит крут (так как это модно).

Я помню как несколько лет назад тоже самое было с darcs. «Он жеж на хацкеле, чо». То есть к конкретной DVCS и к ее «освоению» не относится. Вот если бы после речи Линуса о гите выступил какой-нибудь Стив Джобс, и в духе маковских кейнотов рассказал о hg, о чем бы кричали сейчас хомячки?

Но вобщем что-то в этом есть конечно.

volh ★★
()
Ответ на: комментарий от volh

>Тот же git-log(1) он даже дочитать не сможет, за базаар отвечаю

Я все понимаю, но давно ли у нас крутость и Ъ-шность определяется длиной manpage? И, кстати, отсутствие легкого доступа к мизерному, но часто необходимому функционалу — это однозначный минус.

ЕМНИП отмена последнего коммита в mercurial есть прямо в виде hg uncommit, а в git'е для этого надо повертеться.

linuxfan
()
Ответ на: комментарий от linuxfan

> ЕМНИП отмена последнего коммита в mercurial есть прямо в виде hg uncommit, а в git'е для этого надо повертеться.

git alias не освоили?

yltsrc
()
Ответ на: комментарий от yltsrc

>git alias не освоили?

Ты бы для начала осведомился в вопросе. В git отмена последнего коммита разве делается одной командой?

linuxfan
()
Ответ на: комментарий от linuxfan

>Я все понимаю, но давно ли у нас крутость и Ъ-шность определяется длиной manpage?

Ну не знаю, mplayer(1) меня всегда впечатлял. Хотя есть мнение, что длина мана обратно пропорциональна длине МПХ, уж не знаю насколько это правда.

ЕМНИП отмена последнего коммита в mercurial есть прямо в виде hg uncommit, а в git'е для этого надо повертеться.


Во, пока тут тема. Как в hgk ( через hg view, hgk чего-то не запускается, хотя модуль в конфиг добавил ) можно смотреть изменения для конкретной директории? Наблюдаю сейчас за Томпсоном и Пайком с компанией в репозитории Golang, но вот всю историю смотреть неудобно и медленно.

volh ★★
()
Ответ на: комментарий от linuxfan

>В git отмена последнего коммита разве делается одной командой?

Это смотря что ты понимаешь под отменой, есть несколько комманд, как и в меркуриале ( rollback, backout tip? ). Кстати, в hg я никогда не слышал о uncommit, и hg выдает мне 'unknown command'.

volh ★★
()
Ответ на: комментарий от volh

> Как в hgk ( через hg view, hgk чего-то не запускается, хотя модуль в конфиг добавил ) можно смотреть изменения для конкретной директории?

Никак.

tailgunner ★★★★★
()
Ответ на: комментарий от volh

>Во, пока тут тема

Увы, мое знакомство с mercurial ограничивается «howto для ламеров за 5 минут». uncommit мне просто запомнился по сравнению с ворохом git reset'ов.

Ну не знаю, mplayer(1) меня всегда впечатлял.

Меня тоже. Потому что если бы mplayer и man mplayer писали гитовцы, там был бы ворох опций, позволяющих делать черте-что и по одному теперешнему man mplayer'у на каждый кодек для mencoder'а.

linuxfan
()
Ответ на: комментарий от volh

>и hg выдает мне 'unknown command'.

Так, мне становится стыдно. Я спутал с bzr.

linuxfan
()
Ответ на: комментарий от volh

> Кстати, в hg я никогда не слышал о uncommit

hg qimport -r tip, если надо поправить последний коммит.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Нда, наверное надо таки освоить инфраструктуру emacs vc, а то как-то из консольки да tk-шными приблудами не разогнаться.

volh ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.