Объявлено (https://lists.freebsd.org/pipermail/freebsd-announce/2014-Se...) о выводе из эксплуатации серверной инфраструктуры, обеспечивающей работу сервиса CVSup. Фактически поддержка CVSup была прекращена уже достаточно давно - 8 месяцев назад перестали поступать обновления, а 4 месяца назад содержимое было заменено на файл README.txt, в котором было указано где можно найти архив с копиями репозиториев. Нынешнее изменение ознаменовало отключение серверов, обслуживающих инфраструктуру CVSup. Копию репоизиториев по-прежнему можно найти на ftp.freebsd.org (ftp://ftp.freebsd.org/pub/FreeBSD/development/CVS-archive/).
Администраторам систем рекомендуется обратить внимание на забытые службы CVSup, вызываемые из cron или стартовых скриптов. С июля 2012 года первичной системой контроля версий для исходных текстов FreeBSD и коллекции портов является Subversion (https://www.freebsd.org/doc/ru/books/handbook/svn.html). В качестве замены cvnup можно использовать (https://wiki.freebsd.org/UsersFetchingSource) svnup (http://www.freshports.org/net/svnup/).URL: https://lists.freebsd.org/pipermail/freebsd-announce/2014-Se...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40706
>первичной системой контроля версий для исходных текстов FreeBSD и коллекции портов является SubversionНа Git перейти гордость не позволит))))
тебя забыли спросить, что им лучше
Они под одеялом тихой сапой гит поюзывают, но признаться официально - стесняются.
>На Git перейти гордость не позволит)))http://en.wikipedia.org/wiki/Requirement
http://en.wikipedia.org/wiki/Requirements_analysis
http://en.wikipedia.org/wiki/Software_requirements
http://en.wikipedia.org/wiki/Requirements_management
> http://en.wikipedia.org/wiki/Requirement
> http://en.wikipedia.org/wiki/Requirements_analysis
> http://en.wikipedia.org/wiki/Software_requirements
> http://en.wikipedia.org/wiki/Requirements_managementСмотрите, дети: это называется маркетинговый буллшит.
>> http://en.wikipedia.org/wiki/Requirement
>> http://en.wikipedia.org/wiki/Requirements_analysis
>> http://en.wikipedia.org/wiki/Software_requirements
>> http://en.wikipedia.org/wiki/Requirements_management
> Смотрите, дети: это называется маркетинговый буллшит.Нужно быть дураком от индустрии, что бы управление требованиями, проектными и эксплутационными, так назвать.
Хотя да, в конечном итоге вся деятельность переноситься в стоимость продукта.
В том числе и бестолковая.Вообще-то, родина BSD проектов US, а там проектный цикл в начальной школе уже изучают, на практике.
> Нужно быть дураком от индустрии, что бы управление требованиями, проектными и
> эксплутационными, так назвать.Нужно быть просто дypaком, чтобы все это где-то найти в сабже. Но ты не расстраивайся, сейчас Леня Поттер и прочие редхаты тебе объяснят чего на самом деле хотела видеть индустрия и насколько это далеко было от "планирования" фрибсдшников.
> Вообще-то, родина BSD проектов US, а там проектный цикл в начальной школе
> уже изучают, на практике.На родине ака US околело немало юниксов всех мастей. Да что там, даже полуось от такого гиганта как IBM не выгорела.
Так что то что вы выучили энное количество громких слов и решили ими покозырять - это похвально, но логики вашим рассуждениям это не прибавляет.
>> Нужно быть дураком от индустрии, что бы управление требованиями, проектными и
>> эксплутационными, так назвать.
> Нужно быть просто дypaком, чтобы все это где-то найти в сабже.детка, ты всегда пользуешся тремя буквами алфавита?
вообще-то, еще раз, отличие us пипла как раз и состоит в методической компетентности,
идущей от экономической целесообразности.это везде, как основа. говоришь - результат, подразумеваешь - цикл деминга.
> ты не расстраивайся, сейчас Леня Поттер и прочие редхаты тебе объяснят
поматросят и бросят.
> чего на самом деле хотела видеть индустрия и насколько это далеко
> было от "планирования" фрибсдшников.любительская проект-программа, со своей инфраструктурой, субпроектами и коммюнити.
кто хочет, тот в курсе проектов и насколько они соотвествуют требованиям этого коммюнити.> Вообще-то, родина BSD проектов US, а там проектный цикл в начальной школе
>> уже изучают, на практике.
> На родине ака US околело немало юниксов всех мастей. Да что там,
> даже полуось от такого гиганта как IBM не выгорела.пожалуйста, назовите живой проект операционной системы или нечто системообразующего,
созданный в россии.> но логики вашим рассуждениям это не прибавляет.
а в состоянии ее понять?
> вообще-то, еще раз, отличие us пипла как раз и состоит в методической
> компетентности, идущей от экономической целесообразности.У некоторых пиплов, более известных как "совок", есть интересное свойство: приписывать ВСЕМ пиплам другой станы какие-то по истине волшебные качества. Вы знаете, американцы бывают разные, а на 10 стартапов случается чуть ли не 9 факапов. Хотя казалось бы, какого? А оказывается, американцы тоже разные бывают :). Вон американский IBM с своей полуосью что-то пролетел как фанера над парижем. Банкротами они, конечно, не стали, но тугриков недополучили очень много и видимо прекрасно в курсе такого упущения.
А экономическая целесообразность фрибзды... хахахаха, хорошая шутка :). Из бздей какой-то осмысленный готовый продукт - как из гoвна пуля. Их обставил какой-то там линух, который вообще даже не готовый продукт, а только ядро. Полуфабрикат.
> это везде, как основа. говоришь - результат, подразумеваешь - цикл деминга.
К опенсорсным процессам все это применимо только частично и с большой кучей оговорок.
> поматросят и бросят.
Это можно сказать про совершенно любой софт: ничто не будет существовать вечно. И весь вопрос лишь в том когда это произойдет и по каким мотивам софт будет заброшен. Мало кто хочет использовать CP/M в 2014 году. Потому что он неакутален. Я не возражаю чтобы systemd через несколько десятков лет был phased out по тем же причинам. А пока-что наступила очередь sysv init. Его сейчас phasing out. Здесь и сейчас. Независимо от того нравится ли это господам "я так привык" или нет, вектор тяги в целом по индустрии установился именно такой. Это глобальный консенсус, его уже не удастся отменить.
> любительская проект-программа, со своей инфраструктурой, субпроектами и коммюнити.
> кто хочет, тот в курсе проектов и насколько они соотвествуют требованиям этого коммюнити....поэтому у неудачных и кривых программ комьюнити обычно скромного размера: грузть кактус невзирая на трудности остаются только самые стойкие. А остальные имеют какие-то более осмысленные цели чем борьба с искусственными трудностями на ровном месте.
> пожалуйста, назовите живой проект операционной системы или нечто системообразующего,
> созданный в россии.А зачем мне именно "созданный в россии"? Опенсорс не имеет границ.
> а в состоянии ее понять?
Сложно понять то чего нет. Единственная логика которую я пока вижу - выгораживание задниц и совковое мышление. Но это не логика, это булшит.
Весь текст объясняет стокгольский синдром.
Можете и Git использовать https://wiki.freebsd.org/Git
Официальное зеркало - https://github.com/freebsd
Но основной системой является Subversion, так как во FreeBSD, как и в Apache Fpundation, изначально применяется централизованная модель разработки.
Модель там как раз ещё более распределённая чем в Linux - есть контрибуторы, есть офицеры, но нет диктатора. Единственная причина использования svn вместо git - консерватизм.
> Модель там как раз ещё более распределённая чем в Linux - есть
> контрибуторы, есть офицеры, но нет диктатора. Единственная причина использования svn вместо
> git - консерватизм.А нахрена тебе? Хочешь работать с git по проектам freebsd? git-svn тебе в руль.
А, не намерен и bsd тебе по боку? А что тогда вякаешь в чужой огород?
Я и так работаю с исходниками FreeBSD через git, только git-svn не нужен, когда есть нормальный github репозиторий. Так делают многие, и в такой ситуации непонятно зачем вообще нужен svn.
> Единственная причина использования svn вместо git - консерватизм.А в результате Linux с его "диктатором" пилить удобнее чем BSD с его bunch of masturbating monkeys (c) диктатор.
Какая нафиг распределенная модель разработки может быть с SVN? И о какой распределенной разработке идет речь при таких привычках консерваторов? SVN как таковой заточен на единичный центральный "timeline" коммитов. А git - на множественное параллельное существование форков, обменивающихся фичами. И нет, если вы используете git как "улучшенный svn" - такой workflow не получится, потому что svn его не умеет и отмаппить это в svn - не получится.
> Какая нафиг распределенная модель разработки может быть с SVN? И о какой распределенной разработке идет речь при таких привычках консерваторов?Обычная. Пилишь что-то локально, либо в своей ветке на freebsd.org, потом шлёшь патч, его коммитят в HEAD, если надо cherry-pick'ают в stable ветки. Не надо думать что svn не позволяет какой-то workflow.
> Не надо думать что svn не позволяет какой-то workflow.всё это, конечно, можно делать даже безо всяких систем контроля версий. вопрос только в скорости и удобстве.
собственно, люди в мире этот спор давно уже решили, выбрав в большинстве DVCS. причём выбрали DVCS не пользователи, которым на уши навешали булшита, а разработчики, каждый день использующие инструмент. DVCS оказались инструментом лучше, чем CVCS. по многим причинам. меня вот тоже никто не агитировал, я просто однажды попробовал git… и с тех пор вспоминаю svn как тяжёлое наследие прошлого, плантации, совочки вместо экскаваторов…
> Не надо думать что svn не позволяет какой-то workflow.Как бы это сказать? Он активно стимулирует по дефолту именно такой - централизованный. И обойти это ну не то что совершенно невозможно, но требует уйму левых действий для того что git обеспечивает тyпо сразу после установки.
В svn даже нельзя просто пойти и сделать коммит, джад. Нужно или разворачивать свой сервер (отдельный кластерфак) или получать права на коммит на чужом сервере (тоже кластерфак). А в git я склонировал себе репу и могу коммитить в эту репу как моей душе угодно. То-есть, git сразу же обслуживает не только нужды проекта, но и лично мои локальные нужды. Еще и патч потом поможет сделать. A SVN всем этим похвастаться не может, так что с точки зрения разработчика он делает работу с проектом неудобной. Это может не проблема для десятка старых зубров которые права себе всяко пропишут, зато это проблема для всех остальных, кому эти права не пропишут.
Не надо мне рассказывать что умеет и не умеет svn и git. Просто поймите что есть люди для которых svn работает безо всяких там кластерфаков, локально, не локально, распределённо, не распределённо, и git им нафиг не упал. Остальные же используют репозиторий на github. Один вы только тявкаете кому как что делать.
> Просто поймите что есть люди для которых svn работает безо всяких
> там кластерфаков, локально, не локально, распределённо, не распределённо,При том человеков, для которых все обстоит именно вот так - ну может десятки на всю планету. Те у кого право коммита есть. А всем остальным svn ничего кроме кластерфака предложить не может, ибо локально он работать вообще не умеет сам по себе. Поэтому просто пойти и сделать коммит - АГАЩАЗЗЗЗ. Как минимум придется сервак ставить. Или доказывать что не верблюд, а благонадежный человек, которому право коммита на какой-то еще сервак отсыпать без риска для жизни можно.
А в гит - просто вбахал git clone и потом художествуй себе наздоровье. Вот такое отличие. Одно, зато крайне фатальное для систем наподобие svn.
> и git им нафиг не упал. Остальные же используют репозиторий на github.
> Один вы только тявкаете кому как что делать.Да что вы, я совсем не возражаю если снобы будут по дурости душевной сами же свой проект саботировать. Результат будет заслуженным.
> При том человеков, для которых все обстоит именно вот так - ну может десятки на всю планетуНесколько сотен коммиттеров FreeBSD - именно они SVN и выбрали. Посмотрел бы я на токак бы вы им проповеди почитали.
> Поэтому просто пойти и сделать коммит
А, я всё понял. Вам на код, разработку, изменения вообще плевать, вы поклоняетесь исключительно коммиту как таковому. Он для вас - самоцель. Тогда у меня для вас плохие новости - есть гораздо более удобный инструмент для локальных бесполезных коммитов - RCS.
> Как минимум придется сервак ставить
Чтобы коммитить в локальный svn не нужен сервак.
> Или доказывать что не верблюд, а благонадежный человек
В чужие git репозитории ваши коммиты тоже не попадут пока не докажете.
> А в гит - просто вбахал git clone и потом художествуй себе наздоровье
Да, понадобилась тебе патч к порту сделать - скачай ВСЮ историю всех портов. Вот в SVN вбахал checkout и получил один порт. Мгновенно. Или может вам рассказать про copy/move на стороне сервера вообще без checkout? Куда там. Вам же главное коммитить.
> Несколько сотен коммиттеров FreeBSD - именно они SVN и выбрали.Я рад за них - качественный у них получился саботажик.
> Посмотрел бы я на токак бы вы им проповеди почитали.
А оно мне надо? Я не против того чтобы они простреливали свои пятки, если им так хочется.
> А, я всё понял. Вам на код, разработку, изменения вообще плевать, вы
> поклоняетесь исключительно коммиту как таковому.Я поклоняюсь моему удобству. А коммит - часть процесса разработки. Мне совершенно не очевидно почему надо делать какие-то различия и делать какие-то особые отдельные приседания.
> Он для вас - самоцель. Тогда у меня для вас плохие новости - есть
> гораздо более удобный инструмент для локальных бесполезных коммитов - RCS.Я элементарно не вижу причин как-то сильно делить коммиты на локальные и какие там еще. А RCS - пусть бсдшники им и пользуются ;).
> Чтобы коммитить в локальный svn не нужен сервак.
А чтобы нормально работать с разными ревизиями - нужен. Наверное кому-то нравится, когда большинство действий не работает, но этот кто-то - не я.
> В чужие git репозитории ваши коммиты тоже не попадут пока не докажете.
А это уже второй вопрос. Мне это жить никак не мешает. Я могу шариться по всем ревизиям и делать и с моими и с чужими коммитами все что захочу. А если некто посчитает что ему надо эти изменения - пусть забирает и мержит. Далеко не все коммиты имеет смысл толкать в глотку апстрима. Зато гит мои коммиты учтет и при конфликтах с апстримом предложит сие разрулить, при обновлении, etc. В обычном формате. В целом это делает workflow логичным и удобным.
> Да, понадобилась тебе патч к порту сделать - скачай ВСЮ историю всех портов.
Про --depth и прочую фигню мы читать не будем: настоящие джедаи манов не читают. Хотя при сколь-нибудь активной работе с проектом логично именно полное дерево с всей историей. Вся история обычно весит ну может столько же сколько развернутое дерево сорцов, за счет сжатия и продвинутого хранения дельты.
> Вот в SVN вбахал checkout и получил один порт. Мгновенно.
А потом заметил что там баг порылся и надо на ...цать версий отмотать. И вообще надо еще вон то и вон это. И вот тут как-то так получается что на более-менее большой иерархии svn не только не мгновенно, но и нифига не может без интернета.
> Или может вам рассказать про copy/move на стороне сервера вообще без
> checkout? Куда там. Вам же главное коммитить.Мне вообще на copy/move на стороне сервера. А почему это должно меня колыхать?
> заточен на единичный центральный "timeline" коммитов.бред какой-то от непонимания системы разработки.
вообще, когда дойдет, что центральный репозиторий freebsd - средство _публикации_
достаточно отлаженного и качественно работающего кода, то многое станет на места.
> bunch of masturbating monkeys (c) диктатор.Как мастурбирующая обезьяна с некоторым стажем, ответственно заявляю, что *BSD, за исключением OpenBSD, тут ни при чём, так как в письме, на которое вы ссылаетесь, речь шла конкретно об OpenBSD.
Так что вы бы, это, хотя бы в таких простых вещах не лажали - глядишь, всерьёз бы и ваши слова о деле воспринимались.
> вы ссылаетесь, речь шла конкретно об OpenBSD.К большинству сородичей по моим наблюдениям это тоже вполне применимо.
> лажали - глядишь, всерьёз бы и ваши слова о деле воспринимались.
А зачем мне это? Я на это у...ще все-равно не собираюсь полагаться, поэтому мне все-равно.
Mercurial гораздо эффективнее Git, позволяет сосредоточиться исключительно на разработке проекта, а не на пространных манипуляциях с историями правок, когда внезапно всё "забывается" и появляются баги.
> Mercurial гораздо эффективнее GitЭто ложь. Невменяемые аргументы командной строки, идиотская концепция многоголовости, идиотская система плагинов, да банальный питон в основе. Работать с этим невозможно, и никакая популярность hg этому подтверждение.
> позволяет сосредоточиться исключительно на разработке проекта, а не на пространных манипуляциях с историями правок, когда внезапно всё "забывается" и появляются баги.
Это тоже ложь. git ничего не навязывает - не хотите менять историю - не меняйте. Хотите - вот вам удобнейшие для этого инструменты. mercurial этих инструментов просто не умеет, но "раз у нас их нет, значит у вас они во зло", типичный аргумент сопливого ламера.
>> Mercurial гораздо эффективнее Git
> Это ложь. Невменяемые аргументы командной строки, идиотская концепция многоголовости,
> идиотская система плагинов, да банальный питон в основе. Работать с этим
> невозможно, и никакая популярность hg этому подтверждение.Какая "ложь"? Иди и почитай сам. Там всё на русском языке.
На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle JDK), NetBeans и Mozilla. То есть разрабатывают код, который используется на 98% ПК во всём мире. У GNU/Linux на Git код используется примерно на 3% установок ПК. Это говорит о том, что Git недостаточно проверен и надёжен среди серьёзных разработчиков и, главное, сопровождаемый этой DVCS код сомнительного качества.
Я не понимаю, почему столько ора вокруг Git? Mercurial не так на слуху. Может быть из-за того, что добротная вещь просто не нуждается в обсуждениях. Она как чистый воздух — мы им дышим и не задумываемся об этом. Но если воздух испорчен кем-то, то окружающие о нём начинают говорить и говорить...
>> позволяет сосредоточиться исключительно на разработке проекта, а не на пространных манипуляциях с историями правок, когда внезапно всё "забывается" и появляются баги.
> Это тоже ложь. git ничего не навязывает - не хотите менять историю
> - не меняйте. Хотите - вот вам удобнейшие для этого инструменты.Да вот же конструкционная ошибка Git: http://habrahabr.ru/post/179123/
Если такие ошибки допускаются, то выходит, что инструмент управления версиями нуждается в более тщательном изучении своих нюансов и "подводных камней". Кривая обучения становится длиннее и кривее. Инструмент требует знания многих вещей и в конце концов работа с ним становится многосложной и многословной.> mercurial этих инструментов просто не умеет, но "раз у нас их
> нет, значит у вас они во зло", типичный аргумент сопливого ламера.Умеет. Но их используют в исключительных услучаях. Это не является нормальным.
> На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle
> JDK), NetBeans и Mozilla. То есть разрабатывают код, который используется на
> 98% ПК во всём мире.Java - никому не нужное дeрьмецо, мозилла потеряла большую часть рынка. А вот в git разрабатывается весь остальной софт, который таки установлен на 100% ПК во всём мире.
> Я не понимаю, почему столько ора вокруг Git? Mercurial не так на
> слуху. Может быть из-за того, что добротная вещь просто не нуждается
> в обсуждениях.Или потому что давно проиграла и забыта.
> Да вот же конструкционная ошибка Git: http://habrahabr.ru/post/179123/
Это статья написана безграмотным идиотом, не умеющим использовать инструмент. Кстати, тот же самый сценарий запросто возможен в mercurial.
> Умеет. Но их используют в исключительных услучаях. Это не является нормальным.
Просто потому что они реализованы так, что лучше бы не были реализованы, ими сложно и неприятно пользоваться.
>Java - никому не нужное дeрьмецоВот уж что верно то верно.
А компании вроде Oracle и RedHat где Java является основой бизнеса автоматически становятся дерьмецом.
> Oracle и RedHat
> Java является основой бизнесамда.
> автоматически становятся дерьмецом.Они не становятся, они всегда были. Oracle умеет только покупать и гробить чужое, своя база у них отнюдь не на жаве, но всё равно по всем параметрам сливает постгресу. А про red hat и говорить-то в приличном обществе стыдно.
///---
1.6.2. GitGit — распределенная система контроля версий, которая была разработана для управления исходным кодом ядра Linux. Как и в случае с Mercurial, на начальный дизайн системы оказал влияние Monotone.
Git предоставляет большой список команд, число которых в версии 1.5.0 достигает 139 уникальных единиц. Он имеет репутацию инструмента, сложного для изучения. В сравнении с Git, Mercurial делает упор на простоту.
Что касается производительности — Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.
В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных «перепаковок» собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой «перепаковки», рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что «запакованный» репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.
Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.
Mercurial предоставляет возможность импорта истории версий из репозитория Git.
---///
Источник: http://bacher09.org/hgbook/ru/html/how-did-we-get-here.html#...Вопрос исчерпан?
> На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle
> JDK), NetBeans и Mozilla.3 проекта? Круто. А на git 300 тысяч: https://www.openhub.net/repositories/compare
>> На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle
>> JDK), NetBeans и Mozilla.
> 3 проекта? Круто. А на git 300 тысяч: https://www.openhub.net/repositories/compareА на винде 300 миллионов :)
> https://www.openhub.net/repositories/compareулыбнуло
svn 48%
git 37%
cvs 9%
bazaar - 1%
mercurial - 2%)))))
> А на винде 300 миллионов :)300 миллионов чего? Проектов VCS? Это врядли. А количество тех кто умеет переводить еду в г-но - ну это замечательно, только они погоду не делают.
>> На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle
>> JDK), NetBeans и Mozilla.
> 3 проекта? Круто. А на git 300 тысяч: https://www.openhub.net/repositories/compareВесёлая история с потерей данных в Git: http://www.linux.org.ru/forum/general/10897902
> На Mercurial разрабатывают такие проекты, как OpenJDK (из него делаются сборки Oracle
> JDK), NetBeans и Mozilla.Тем хуже для них - нагрели себя на толпу разработчиков. В результате куча разработчиков пойдет кодить хром. Потому что гoвняная VCS - это таки минус проекта при прочих равных. А git что, он людям с програмерским складом ума в руку как влитой ложится. Я в 90% случаев чисто интуитивно знаю что набрать - потому что когда я делаю некое действие, мыслю так же как те кто кодил инструмент для программистов.
> типичный аргумент сопливого ламера.Так это же iZEN. Ламерство - его визитная карточка.
Ну это замечание конечно обязательно должно было появиться в теме про системы контроля версий =)))
> Mercurial гораздо эффективнее Git,Оно и видно - все на гит почему-то свалили, а гитхаб стал новым крупнейшим опенсорсным хостингом, пока остальные щелкали клювами или впаривали третьесортные базары и меркуриалы.
> проекта, а не на пространных манипуляциях с историями правок, когда внезапно
> всё "забывается" и появляются баги.В git как раз ничего не забывается. Он по этой части штука крутая.
> Оно и видно - все на гит почему-то свалили, а гитхаб стал
> новым крупнейшим опенсорсным хостингом, пока остальные щелкали клювами или впаривали третьесортные
> базары и меркуриалы.Ну, я не считаю git лучшей системой контроля версий, а github - лучшей площадкой. И меня мало интересует, что думают таинственные "все". Выбор - это хорошо, это позволяет выбрать, что более удобно каждому: а поклоняться "ейн рейх, ейн фюрер, ейн гит"... люди просто хотят всунуть git в каждую дырку, решить им все проблемы человечества, и идеализируют его насквозь - это уже какое-то помешательство. Скоро будут расстреливать тех, кто не поклоняется git. :)
ps. Продавайте git в другом месте. :-)
> Ну, я не считаю git лучшей системой контроля версий, а github - лучшей площадкой. И меня мало интересует,Поймите, "мало интересуете" именно вы. Храните исходники в mercurial или fossil, на вашем любимом небыдлo-хостинге или локалхосте, никто слова не скажет. Но вам самому будет нечего сказать, когда потенциальные контрибуторы вместо того чтобы pull покрутят пальцем у виска и пойдут дальше. Про git говорят на каждом шагу именно потому что это не все понимают.
Если вы чётко осознаёте, что не хотите быть частью F/OSS сообщества, пилите проеты исключительно для себя и не ждёте на того что их будуи использовать другие люди, ни того что другие люди захотят их улучшить, то вам про git рассказывать действительно не надо.
> самому будет нечего сказать, когда потенциальные контрибуторы вместо того чтобы pull
> покрутят пальцем у виска и пойдут дальше.Так буратино вообще cannot into опенсорсные процессы. Почему питон и всякая наколенщина? А чтоб он один мог все по бырому накодить. При этом что вываливай сорц, что нет. Процесс не взлетит.
> Если вы чётко осознаёте, что не хотите быть частью F/OSS сообществаВот в чём я точно уверен, так это в том, что OpenBSD с вашим F/OSS сообществом не по пути.
Ваше "эффективное, никаких NIH, никаких DRY" сообщество - это куча зависимостей на каждый чих, это "сделаем это на ruby и js, а потом ещё больше ruby и js и ещё больше зависимостей", это непомерное чванство, самоуверенность, общение сленгом, при котором Эллочка-людоедка - гигант мысли, и при этом отчаянное желание НЕ ПОНИМАТЬ ПРОБЛЕМУ. А реальные проблемы решаются там, где живёт CVS. :)
Я практически уверен, что ваш путь развития - это тупик. Просто сильно переслащенный венчурными капиталами. Просто подрасли дети, которые не застали первое лопание доткомов, и начали делать то же самое. И лопнет оно точно тем же образом, потому что собирает те же самые ошибки.
> Но вам самому будет нечего сказать, когда потенциальные контрибуторы вместо того чтобы pull покрутят пальцем у виска и пойдут дальше.
А если нужны ишшуи? Или нормальная отметка о состояниях, или что-то ещё? Кто вам вообще сказал, что эти пулл-реквесты вообще первичны? Вы просто сами и доказываете, что проблемы вы не видите, и дальше взаимоотношений "разработчик - разработчик" не смотрите. Хотя и тут не всё гладко, как вы расписываете. Вы вдолбили себе "панацейность" git, и теперь уверяете, что все проблемы можно им решить. А если быть ещё точнее, то подгоняете проблемы под возможности git. А всё остальное остаётся вне вашего поля зрения. Вот такой вот современный F/OSS...
То, что такие контрибуторы пойдут дальше - это даже хорошо. :) Потому что "нафигачить кода" - это должно быть последнее действие, а не первое. :)
> Вот в чём я точно уверен, так это в том, что OpenBSD с вашим F/OSS сообществом не по пути.Полностью согласен. Этой замшелой помойке вообще ни с чем не по пути, и ни открытостью, ни свободой там и не пахло.
> Ваше "эффективное, никаких
Это пропущу, какая-то шизофазия с приплетением каких-то капиталов, доткомов и прочей бредятины.
> А если нужны ишшуи?
И вы ещё что-то о сленге вякаяете? На GH есть issues.
> дальше взаимоотношений "разработчик - разработчик" не смотрите
Нет, это вы дальше своего CVS не смотрите. Я не говорю что git и github решает все проблемы, но вот кучу проблем которые есть у cvs и подходе к разработке применяемому в том же openbsd они решают с блеском. Но я понял, вам что-то втолковывать бесполезно, ибо мозг настроен под CVS и все новые идеи принимаются крайне враждебно, и никаких проблем вы никогда не признаете.
> То, что такие контрибуторы пойдут дальше - это даже хорошо
Ну вот поэтому OpenBSD и находится в том месте где находится.
> с вашим F/OSS сообществом не по пути.А мне не по пути с проектом где кладут @#$ на мои задачи и проблемы.
> это куча зависимостей на каждый чих,
Между строк читается: "да вы охренели - код реюзать смеете?!". Как ни странно, реюз кода из чужих библиотек позволяет не париться с решением давно решенной проблемы самому. Кто не верит что это круто - может пойти написать свое ядро операционки и драйвера для разминки. О юзермодовых либах мы подумаем потом, если запал NIH-ера к тому моменту еще не иссякнет.
> это "сделаем это на ruby и js, а потом ещё больше ruby и js и ещё больше зависимостей",
Пришел буратина и стереотипно расписался за всех и сразу. И эти люди что-то еще вякают про стереотипы...
> и при этом отчаянное желание НЕ ПОНИМАТЬ ПРОБЛЕМУ.
Почему же. Свои проблемы я нормально понимаю. А высосанную из пальца борьбу с ветряными мельницами я и правда не намерен понимать.
> А реальные проблемы решаются там, где живёт CVS. :)
И какие же проблемы удалось решить этим решателям? Наверное, проблемы избытка пользователей и разработчиков в проекте...
> доткомов, и начали делать то же самое. И лопнет оно точно
> тем же образом, потому что собирает те же самые ошибки.Я вообще к доткомам не отношусь по большому счету.
> А если нужны ишшуи? Или нормальная отметка о состояниях, или что-то ещё?
Тогда вам к бактрекеру и сборочной системе, очевидно.
> Кто вам вообще сказал, что эти пулл-реквесты вообще первичны?Первичен удобный для разработчиков процесс, если проект заинтересован в том чтобы его разрабатывали.
> то подгоняете проблемы под возможности git. А всё остальное остаётся вне
> вашего поля зрения. Вот такой вот современный F/OSS...Git позволяет забыть о VCSной части проблемы т.к. не перепихивает проблемы разработчиков, тестировщиков и экспериментаторов на кого-то еще а вместо этого успешно решает их. Могут быть какие-то иные проблемы, они вне сферы умений гит. Но зато в пределах умений других инструментов. И если эти инструменты не умеют интегрироваться с гитом - грош им цена в базарный день по состоянию на 2014 год.
> То, что такие контрибуторы пойдут дальше - это даже хорошо. :)
Ну еще бы. Контрибуторы не будут тратить время на работу в мусорный бак.
> Потому что "нафигачить кода" - это должно быть последнее действие, а не первое. :)
Такое заявления от корябателя всякой фигни на питоне смотрится просто эталоном лицемерия.
> лучшей площадкой. И меня мало интересует, что думают таинственные "все".Это же можно сказать про тебя и твое мнение со стороны остальных. Ты тоже входишь в множество "все". Твое мнение imho стоит просто спускать в /dev/null за отсутствием внятных аргументов.
> Выбор - это хорошо, это позволяет выбрать, что более удобно каждому:
Я как-то не вижу особого удобства езды на деревянной телеге запряженной парой лошадей по дорогам общего пользования. Ни вам конюшен, ни вам поилок. Но формально как бы можно, с кучей оговорок, это да.
> git в каждую дырку, решить им все проблемы человечества, и идеализируют
> его насквозь -Как бы это сказать? Он выбился в лидеры в своем сегменте и задает погоду. При том такое положение дел - достаточно обоснованное.
И вообще, какого хрена ты вот тут на опеннете используешь единственный TCP/IP и HTTP? Вдруг тебе IPX или там Gopher симпатичнее. Только вот удачи переписываться с местными по этим протоколом. Правда жизни такова что инструментарий для взаимодействия с окружающими - таки определяется и неким глобальным консенсусом.
> это уже какое-то помешательство. Скоро будут расстреливать тех,
> кто не поклоняется git. :)Зачем же сразу расстреливать? Будешь взаимодействовать сам с собою, правою рукою. И будет у тебя чудные "открытые" проекты. С одним участником - тобой. Примерно как если захотеть чтобы я взаимодействовал с тобой по IPX какому-нибудь - я его попросту не буду разворачивать ради одного тебя на всю планету.
> ps. Продавайте git в другом месте. :-)
Он в общем то бесплатный. Хотя если очень хочется заплатить - наверное это можно...
небольшое уточнение: если уж TCP, то тогда SPX.
> небольшое уточнение: если уж TCP, то тогда SPX.Да блин, надо было IPX/SPX писать :)
Тупость, стереотипность, левые аналогии. Полное списание модели поведения с известно-откуда, и слепое ему подражание. Это вы, что ли, opensource строите? Вот от чего хотелось бы держаться подальше, как и от вашей культуры. И от вашего опенсорца.Культура Unix десятилетиями строилась. На фундаменте. И люди, когда хотели делать, изучали этот фундамент, и то, почему это работает. А сейчас никто ничего понимать не хочет - прочитал где-то басен, льстящих слуху, что все вокруг тупые, и только у чётких пацанов монаполия на истину, просто отрезал от мировосприятия часть проблем, сделав какой-то сублимированный мирок - и там сублимирует, постоянно бесясь от того, что на самом деле реальность не такая, как ему хочется (а реальность не такая. и ваши представления о реальности - сильно искажены, сколько бы вы под себя удобных фактов не подгоняли)
Хорошо свидетельствовал о вас Иван Тургенев:
... вот как должны современные молодые люди выражаться! И как, подумаешь, им не идти за вами! Прежде молодым людям приходилось учиться; не хотелось им прослыть за невежд, так они поневоле трудились. А теперь им стоит сказать: все на свете вздор! — и дело в шляпе. Молодые люди обрадовались. И в самом деле, прежде они просто были болваны, а теперь они вдруг стали ...
... тут я продолжу - "эффективные разработчики".
Лучше одумайтесь, пока не поздно. Ибо, когда будет поздно, мои слова вспомните... но будет, как всегда, поздно. OpenSource настолько эффективен, что его тотальной победе только ваша культура (и ваше присутствие) всё время мешает...
Сначала ты казался вменяемым, но просто не успевшим оценить новые технологии. Теперь понятно что это далеко не так, и ты неадекват с ОБВМ. Извини, но таки да - opensource строим мы, а вы, действительно, держитесь подальше в своей выгребной яме из бреда, иллюзий и CVS - вклада вы никакого внести всё равно не способны.> прочитал где-то басен, льстящих слуху, что все вокруг тупые, и только у чётких пацанов монаполия на истину, просто отрезал от мировосприятия часть проблем, сделав какой-то сублимированный мирок - и там сублимирует
Ты вот прям слово в слово описал впечатление которое сам производишь.
> Тyпость, стереотипность, левые аналогии.Кого же мне это напоминает?
> Полное списание модели поведения с известно-откуда,
> и слепое ему подражание.Ты что, автобиографию пишешь?
> Это вы, что ли, opensource строите?
В том числе и мы. Результат работы процесса составляет сумма работ его участников.
> Вот от чего хотелось бы держаться подальше, как и от вашей культуры.
> И от вашего опенсорца.Ты так говоришь, как будто кому-то от этого станет хуже. Учитывая что я не заметил способность и желание делать что-то полезное с твоей стороны для проектов которые тебя держат на плаву - я не понимаю кто и что теряет от этого махания кулаками в воздух. Я что-то упускаю?
> Культура Unix десятилетиями строилась. На фундаменте.
Юникс - проприетарная система от AT&T. Той самой компании, которая потом таскала по судам бсдшников. Такая вот интересная культура. Все остальное - придумано фанатами сферического юниксвея в вакууме. При том каждый фанат трактует юниксвейность по своему.
> И люди, когда хотели делать, изучали этот фундамент, и то, почему это работает.
Я вот понимаю этот фундамент. И понимаю что местами это превратилось в стоянку пещерного человека. В XXI веке у компьютерных систем оказалось здорово больше применений и задач чем было в конце 70-х, придумали уйму новых подходов, зарекомендовавших себя эффективными и прочая.
> А сейчас никто ничего понимать не хочет - прочитал где-то басен, льстящих слуху,
Почему же. Я понимаю что мне нужны работающие компьютерные системы, делающие то что мне нужно. Для этого нужна операционная система. Чем она будет гибче и кастомизабельнее - тем шире горизонты моих возможностей. Поэтому утыкаться в подходы конца 70-х как единственно верные я не собираюсь. Хочешь парочку примеров фундаментальных упущений традиционных юниксных подходов?
> что все вокруг тyпые, и только у чётких пацанов
Это ты так про "юниксвэйщиков" типа себя, которые вечно знают лучше всех как правильно и игнорируют уйму проблем, не вписывающихся в их парадигмы? :)
> монаполия на истину,
Это как? Эксклюзивные права на картину "Мона Лиза" чтоли?
> просто отрезал от мировосприятия часть проблем, сделав какой-то сублимированный мирок - и
> там сублимирует, постоянно бесясь от того, что на самом деле реальность не такая,
> как ему хочется (а реальность не такая.Какое хорошее описание юниксвэйщиков, уткнувшихся в один подход и старательно отбрасывающих все задачи которые на него плохо ложатся. А мне так не нравится - я не драпаю от технических моментов и не втираю очки что "это не нyжно". Первична нужность человекам задач, а все эти юниксвэи и прочие - лишь метод достижения целей. Один из. Методы могут быть разные, а их можно улучшать и расширять. А если ты хочешь пользоваться компьютерами в стиле семидесятых - ну вот сиди там в своем маргинальном болотце и урезай свои задачи под то что может обеспечить тебе твой упертый подход.
> и ваши представления о реальности - сильно искажены, сколько бы вы под себя
> удобных фактов не подгоняли)Я как раз не люблю подгон решений под ответ. А зачем мне самому себя обманывать? Это контрпродуктивно. Это у тебя привилегия долбиться в пол, поклоняясь юниксвею и прочим. А у меня свой путь, с некими задачами которые я считаю нужными как минимум мне (а возможно так выйдет что и кому-то еще). На этом пути мне в ряде направлений с рядом проектов и технологий. И я не вижу ничего зазорного в том чтобы их брать, дорабатывать, улучшать и адаптировать под задачу вместо того чтобы просто долбаться лбом в пол - ах, великий и ужасный юниксвей, бла-бла-бла.
> но будет, как всегда, поздно. OpenSource настолько эффективен, что его тотальной
> победе только ваша культура (и ваше присутствие) всё время мешает...Я думаю что ты про рафинированный сферический опенсорс в вакууме. А я за решения которые держат меня на плаву и решают мои задачи. И вообще я больше за FreeSoftware. Потому что понятие OpenSource еще не гарантирует нормальную защиту прав и интересов участников процесса.
> На Git перейти гордость не позволит))))не гордость — просто dvcs ещё недостаточно протухли.
иретики...в openbsd я сделал cvsync на всё... получилось 4 гб... зато там есть всё, с первых дней и на всю жизнь - код, порты, веб-сайт. особенно по последнему с вкладкой -D лазить интересно - можно посмотреть состояние официального сайта на любой день... вот так, например, сайт выглядел 14 лет назад http://28.51t.ru/
> в openbsd я сделал cvsync на всё... получилось 4 гб...svnmirror получится 2GB, а git - полгигабайта. И работать будет в 2 и 10 раз быстрее соответственно.
Как git работает с AUR, сколько места оно занимает и как "быстро" работает - я видел...Кстати, у git есть такие возможности, чтобы загруженные с сайта тарболы дальше продолжать обновлять через git?
Кстати#2, а как в git сделать срез "как репозиторий выглядел в определённую дату"?
> Как git работает с AUR, сколько места оно занимает и как "быстро" работает - я видел...Не знаю что вы там видели и с чем сравнивали, но с FreeBSD'шными исходниками в git работать на порядок быстрее чем с svn. Когда я начинал работать с DVCS, а начинал я с mercurial, репозиторий конвертился неделю, и клонировался около часа (локально!), так что о hg можно даже не заикаться.
> Кстати, у git есть такие возможности, чтобы загруженные с сайта тарболы дальше продолжать обновлять через git?
Тарболы чего? Если вам запакуют в тарбол репозиторий, разумеется им можно будет пользоваться как локально созданным.
> Кстати#2, а как в git сделать срез "как репозиторий выглядел в определённую дату"?
git co '@{yesterday}', git co '@{2014-09-30 12:00}', git co '@{1 hour ago}'
> Тарболы чего? Если вам запакуют в тарбол репозиторий, разумеется им можно будет пользоваться как локально созданным.надо, чтобы продолжалась история, но чтобы оверхеда по размеру не было :)
> git co '@{yesterday}', git co '@{2014-09-30 12:00}', git co '@{1 hour ago}'
ясно... как-нибудь, может даже сегодня, попробую сконвертировать...
> надо, чтобы продолжалась история, но чтобы оверхеда по размеру не было :)Что вы имеете в виду под оверхедом по размеру? Продолжающуюся историю как-бы надо где-то хранить.
> надо, чтобы продолжалась история, но чтобы оверхеда по размеру не было :)Чудес не бывает: или уж история хранится, или уж нет. И если что - у гита в менее чем гиг лезет, на секундочку, ВЕСЬ НАБОР ВЕРСИЙ ЯДРА LINUX. С древнего 2.6.11 до распоследнего 3.17-rc6. То-есть, файл базы с полной историей со времен царя гороха весит примерно как рабочий набор файлов. Т.е. утяжеление - в пару раз, а одних только tagged версий там 389 штук на данный момент. Хотя можно шариться по всем коммитам вообще, просто tag'ом помечают нечто логически оформившееся, что по идее должно собираться и не падать вот так сходу.
>> надо, чтобы продолжалась история, но чтобы оверхеда по размеру не было :)
> Чудес не бывает: или уж история хранится, или уж нет.Дело не в хранении исходников. Просто человек получает .tar.gz на cd или выкачивает через ftp, а затем, не выкачивая заново сотни мегабайт, может дальше продолжать обновлять этот архив. У CVS тут совсем незначительный оверхед в размере архива, поэтому оно так и идёт "как есть". А там уже - хошь на другую ветку переключайся, хошь эту обновляй. Содержимое anoncvs никто же не включает в поставку этих tar.gz :)
> Дело не в хранении исходников. Просто человек получает .tar.gz на cd или
> выкачивает через ftp, а затем, не выкачивая заново сотни мегабайт, может
> дальше продолжать обновлять этот архив.Ну и с git так будет, безо всякого оверхеда.. Я даже больше скажу, когда человек делает git clone, он по сути качает такой же архив, только оный генерится на сервере налету, поэтому подобные костыли просто не нужны.
сейчас к тебе прибегут с коронным аргументом: «а git не умеет докачку! я в svn могу ^c нажать, и потом докачать остаток, а в гите если коннект слетел, то всё сначала качай!»
> сейчас к тебе прибегут с коронным аргументом: «а git не умеет докачку!Да и фиг с ним, имхо - 1 раз в жизни я могу распереться скачать 600 метров кернела со всей историей. Ну или при плохой конективити типа GPRS без надежды на какой либо апгрейд - получить "флоппинетом". А потом дельты мизерные, их хоть по GPRS качать можно не напрягаясь. Хз, мне это жить не мешает.
> выкачивает через ftp, а затем, не выкачивая заново сотни мегабайт, может
> дальше продолжать обновлять этот архив.Ну так git как-то так и работает - однажды качаешь большую чушку, получаешь локальную базу со всеми ревизиями (если не надо всю историю - глубина выкачивания настраивается). А потом он будет качать только весьма эффективную дельту относительно того что уже есть. Считанные мегабайты на релиз нового ядра линуха, например. Намного меньше чем тарбол этой версии ядра с HTTP. При этом можно за 5 секунд отмотать на какой-нибудь 3.12-rc3, если это за каким-то стало надо. Времени уйдет несколько секунд - на перелопачивание файлов. При том формат хранения весьма эффективен - в нечто типа гигабайта влезают ВСЕ РЕВИЗИИ ядра Linux. С 2.6.11 до текущего. Сколько все это весит как тарболы я даже представить себе боюсь - там более 300 одних только tags. Не говоря о доступности коммитов.
> У CVS тут совсем незначительный оверхед в размере архива,
У CVS феерический пи...ц и с передачей отличий, и с мотанием по версиям. Если его как VCS рассматривать. Да и как файлокачалка там мало чего хорошего.
> поэтому оно так и идёт "как есть".
Оно идет как есть только за счет ретардов и некрофилов которые "так привыкли" и игнорируют тот факт что можно делать удобнее и эффективнее. Но да, для этого знания инструментария придется подтянуть.
> А там уже - хошь на другую ветку переключайся, хошь эту обновляй.
Только ожидалка ожидать отсохнет ждать апдейта мало-мальски активного проекта. И сетевуха качать полинтернета задолбается если эта другая ветка заметно отличается. А гит ни байта не передаст - он из локальной базы построит нужное состояние, такое какое было на момент запрошенной версии. И работать это все будет со скоростью записи на диск, плюс-минус. По крайней мере на современных машинах. Как на первом пне - не знаю и знать не хочу.
> Содержимое anoncvs никто же не включает в поставку этих tar.gz :)Поэтому если поменялась половина файлов - будешь полинтернета заново выкачивать. Очень круто и все такое - всего полчаса даунлоада и у тебя запрошенная версия. А гит за единицы секунд применит нужное состояние...
>> выкачивает через ftp, а затем, не выкачивая заново сотни мегабайт, может
>> дальше продолжать обновлять этот архив.
> Ну так git как-то так и работает - однажды качаешь большую чушку,
> получаешь локальную базу со всеми ревизиями (если не надо всю историю
> - глубина выкачивания настраивается). А потом он будет качать только весьма
> эффективную дельту относительно того что уже есть. Считанные мегабайты на релиз
> нового ядра линуха, например.Я так же получаю обновления локального дерева портов через portsnap(8). Вот только для этого никакой DVCS не надо.
> Я так же получаю обновления локального дерева портов через portsnap(8). Вот только
> для этого никакой DVCS не надо.Тут умные дяди говорят про VCS. Иди отсюда со своим portsnap, он вообще не при чём.
> для этого никакой DVCS не надо.Упыри попутавшие VCS с файлокачалкой - вообще отдельная история.
>> для этого никакой DVCS не надо.
> Упыри попутавшие VCS с файлокачалкой - вообще отдельная история.Так почему Git не имеет возможности докачки при обрыве соединения?
> Так почему Git не имеет возможности докачки при обрыве соединения?Научись читать? В https://www.opennet.ru/openforum/vsluhforumID3/99130.html#120 я вроде нормально объяснил. Скорее всего большинство разработчиков как-то так же считают.
да оставь ты их в покое, у них до сих пор прошлый век, распространение тарболами, вся вот эта фигня. то, что git тоже умеет разных гитик, их не волнует: они еле-еле svn освоили за кучу лет, а тут вообще придётся мозг перестраивать и ломать привычные паттерны.
> да оставь ты их в покое, у них до сих пор прошлый векболее озабочен тем, что в россии позапрошлый век.
>распространение тарболами, вся вот эта фигня.
$ svnrdump dump -r 250000:272127 svn://svn.freebsd.org/base/stable/9/ > svn.dump
если уж так хочется.
> то, что git тоже умеет разных гитик
с каких пор транспорт заменяет интеллект разработчика?
вообще, тема не стоит яичной скорлупы. в bsd проекте был субпроект смены cvs на иную систему управления репозирарием кодап с минимальными затратами, при том что cvs репозитарий содержит все изменения с 1994 года.
действующим советом был выбран вариант миграции на svn как наиболее оптимальный вариант.>а тут вообще придётся мозг перестраивать и ломать привычные паттерны.
ты из штатов пишешь и вчера лично общался с разработчиками? нет? может у тебя проблемы? =)
> с каких пор транспорт заменяет интеллект разработчика?Git не столько транспорт сколько DVCS. Хотя транспорт с дельтами там тоже довольно эффективный, но его осноная фича даже не в том.
> cvs на иную систему управления репозирарием кодап с минимальными затратами,
Экономить на одном из основных рабочих инструментов - не умно, мягко говоря.
> действующим советом был выбран вариант миграции на svn как наиболее оптимальный вариант.
И именно поэтому половина разрабоитчиков под одеялом поюзывает гит, да? Юзеров гита которые бы хотели svn-ом пользоваться мне что-то не попадалось, а вот наоборот - бывает.
> ты из штатов пишешь и вчера лично общался с разработчиками? нет? может
> у тебя проблемы? =)У кого там будут проблемы - это мы еще посморим. Например, тынц: http://w3techs.com/diagram/history_technology/os-bsd
>> с каких пор транспорт заменяет интеллект разработчика?
> Git не столько транспорт сколько DVCS. Хотя транспорт с дельтами там тоже
> довольно эффективный, но его осноная фича даже не в том.если человек разрабатывает проект, имеет такую цель, то может обойтись даже vi, rcs и mail.
если не намерен, то и new-super-cool-dcvs-glit-and-split не поможет.
будет писать портянки на форумах о необходимости ...бла-бла...что практика и подверждает.
> Экономить на одном из основных рабочих инструментов - не умно, мягко говоря.
а в чем потери, опишите пожалуйста?
желательно в цифрах.
> У кого там будут проблемы - это мы еще посморим.читаю это с 1997 года.
> если человек разрабатывает проект, имеет такую цель, то может обойтись даже vi,
> rcs и mail.Да что там, первые программы ассемблировали руками, на бумажке. И вбивали тумблерами на шине, пошагово. Так что вы с вашим vi, rcs и mail - кучка мягкотелых пижонов. В чем проблема? В том что все это несколько нагибает эффективность. И одно дело когда выбора нет по чисто техническим причинам (если ты запускаешь какой-нибудь там первый компьютер в городе - тебе чисто технически негде софт взять) и совсем другое - сознательно нагибать рабочий процесс при том что хорошие решения есть. Это уже попахивает чем-то типа саботажа или просто контрпродуктивной упертости в терминальной стадии.
> если не намерен, то и new-super-cool-dcvs-glit-and-split не поможет.
> будет писать портянки на форумах о необходимости ...бла-бла...Я могу заассемблировать программу на бумажке и вбить ее тумблерами, пошагово. Ну так, если сильно приспичило. Но могу != хочу программировать именно так. А зачем мне создавать сеюе искусственные сложности, если можно взять нормальный програмерский редактор с подсветкой синтаксиса, а сборку спихнуть на компилятор? Ну вот и с VCS'ами как-то так же ;).
> что практика и подверждает.
Пока-что я вижу что практика показывает нам нечто типа http://w3techs.com/diagram/history_technology/os-bsd и я вижу на то вполне валидные причины.
> а в чем потери, опишите пожалуйста?
В удобстве разработчика/тестировщика/экспериментатора/etc. Возможность быстро работать с ревизиями не выкачивая каждый раз по половине интернета и не делая больших отличий между локальными и ремотными коммитами - это хорошо. Это позволяет просто сделать то что хотел, а не бороться с искусственными сложностями на ровном месте.
> желательно в цифрах.
Сложно замерять - я вообще забыл когда я в последний раз что-то коммитил в svn. Это было давно и неправда.
> читаю это с 1997 года.
А прикольно такие как ты потом истекают от новостей про то что всякие там яху и апачи, яндексы и рамблеры и кого я там еще забыл - драпают на пингвины :). Не знаю как там с 1997 года, но в последние лет пять с бздов слиняло довольно много контор.
>в удобстве разработчика/тестировщика/экспериментатора/etc.
репозитарий freebsd - средство публикации кода.
>быстро работать с ревизиями
до сих пор думал, что работать с ревизиями - это анализ, разработка архитектуры-кода.
ан нет.
>не выкачивая каждый раз по половине интернета#cd /usr/src/sys
# find . -type f | wc -l
10849# time svn update
real 0m23.561s
# cd rockbox
# find . -type f | wc -l
8677# time git pull
real 0m19.236s
может хватит про пол-интернета, детка?
> и не делая больших отличий между локальными и ремотными коммитами - это хорошо.
нахрен такого из рабочей группы.
>> желательно в цифрах.
>сложно замерять ...а чего тогда трандеть в консерватории?
> Когда я начинал работать с DVCS, а начинал я с mercurial,
> репозиторий конвертился неделю, и клонировался около часа (локально!), так что о
> hg можно даже не заикаться.В каком году это было?
>> Когда я начинал работать с DVCS, а начинал я с mercurial,
>> репозиторий конвертился неделю, и клонировался около часа (локально!), так что о
>> hg можно даже не заикаться.
> В каком году это было?В 2012-м. Только не надо мне рассказывать что hg стал быстрее, ибо с месяц назад коллега в точности повторил мой опыт.
> Когда я начинал работать с DVCS, а начинал я с mercurial,
> репозиторий конвертился неделю, и клонировался около часа (локально!), так что о
> hg можно даже не заикаться.
> В 2012-м. Только не надо мне рассказывать что hg стал быстрее, ибо с месяц назад коллега в точности повторил мой опыт.Откуда конвертировался? Клонирование локального репозитория hg выполняет символическими ссылками, если есть такая возможность. Может проблемы с ФС?
> Откуда конвертировался? Клонирование локального репозитория hg выполняет символическими
> ссылками, если есть такая возможность. Может проблемы с ФС?Проблемы с твоей головой, ибо ты символические ссылки от жёстких не отличаешь, а лезешь в обсуждения VCS.
>> Откуда конвертировался? Клонирование локального репозитория hg выполняет символическими
>> ссылками, если есть такая возможность. Может проблемы с ФС?
> Проблемы с твоей головой, ибо ты символические ссылки от жёстких не отличаешь,
> а лезешь в обсуждения VCS.Ну да, жёсткими. Так проблема с ФС или где?
Проблема с твоей головой, я же сказал.
Всё понятно. Хардлинки не пересекают пространства ФС. Если клонирование локального репозитория происходит на другой жёсткий диск, в другую ФС, то будет простое копирование файлов средствами hg. То есть будет затрачено в том числе время на дополнительную верификацию копируемой информации.% cd /downloads0/netbeans.org/
% date && hg clone main devel && date
пятница, 3 октября 2014 г. 02:27:45 (MSK)
обновляемся на ветку default
92565 файлов обновлено, 0 слито, 0 удалено, 0 c конфликтами
пятница, 3 октября 2014 г. 02:29:01 (MSK)
% du -d0 -h main devel
3,4G main
440M devel
Клонирование локального репозитория, когда хардлинки не создаются:% mkdir /downloads2/netbeans.org/
% date && hg clone main /downloads2/netbeans.org/devel2 && date
пятница, 3 октября 2014 г. 02:36:40 (MSK)
обновляемся на ветку default
92565 файлов обновлено, 0 слито, 0 удалено, 0 c конфликтами
пятница, 3 октября 2014 г. 02:43:12 (MSK)
% du -d0 -h main /downloads2/netbeans.org/devel2
3,4G main
3,4G /downloads2/netbeans.org/devel2% hg vers
Распределенная SCM Mercurial (версия 3.1.1)
(подробнее см. http://mercurial.selenic.com)(С) 2005-2014 Matt Mackall и другие.
Это свободное ПО; условия распространения см. в исходном коде.
НИКАКИХ ГАРАНТИЙ НЕ ПРЕДОСТАВЛЯЕТСЯ, в том числе на пригодность для
коммерческого использования и для решения конкретных задач.
> Как git работает с AUR, сколько места оно занимает и как "быстро"
> работает - я видел...А я видел как git разворачивает проект размером с линевый кернель за несколько секунд. Перелопатив половину файлов и не переслав ни бита по сети. CVS/SVN для такого как раком до китая.
Сомневаюсь, что сотни тысяч файлов можно развернуть за несколько секунд на обычный носитель даже чисто теоретически.Ну, у меня вся история OpenBSD тоже хранится, в CVS. Вся, начиная с самого начала проекта, с ветки netbsd_1_1_1 :) Все сырцы, все поколения иксов, все порты, все варианты веб-сайта - в общем, полная история всего проекта. Могу иметь к ней доступ без наличия сети.
Если мне не нужна история - могу использовать просто cvs up с любого из зеркал, храня только ту ветку исходников/портов, которая мне нужна для реального использования.
Я не вижу тут проблемы.
> Сомневаюсь, что сотни тысяч файлов можно развернуть за несколько секунд на обычный
> носитель даже чисто теоретически.Я смотрю ты под своей openbsd и файловых систем нормальных не видел, какие уж тут vcs.
> Я смотрю ты под своей openbsd и файловых систем нормальных не видел,
> какие уж тут vcs.бедный буратино бедный.
> Сомневаюсь, что сотни тысяч файлов можно развернуть за несколько секунд на обычный
> носитель даже чисто теоретически.Можно, можно. EXT4 сам по себе быстрый, а у меня еще и невъ...й дисковый буфер. В него весь working set умещается, со всеми вытекающими, как то постоянный cache hit и скорость более характерная для ram-диска чем hdd. А даже если не повезло, ext4 и сам по себе достаточно резвый. Совсем на холодную конечно работает медленнее на чтение, но тоже прилично. Как я уже сказал - я не люблю тормозливые компьютеры. Теперь ты понимаешь зачем мне СОВРЕМЕННЫЙ компьютер? Гигазы оперативки будут частично использованы VM-ами, а частично пойдут под большой дисковый буфер. Свопа нет как класса - не вижу смысла эмулировать оперативку тормозным винчом если оперативки и без этого достаточно. Зато программы не заклинит потому что страницу надо вынуть с механики, которая полсекунды будет головы гонять. Несколько дисков - позволяет разнести нагрузку. Система вообще живет на отдельном SSD, поэтому взлетает со скоростью ракеты и никогда не тормозит. Это оптимизация I/O. Ну и мощный проц - который с удовольствием соберет софт в 8 потоков не напрягаясь.
> Ну, у меня вся история OpenBSD тоже хранится, в CVS. Вся, начиная
> с самого начала проекта, с ветки netbsd_1_1_1 :)Что я тут могу сказать? Это оправдывает твой ник на все 120%. Хранить историю в CVS? Как бы это сказать? Git даже сервера не требует - каждая репа самодостаточна by design. А cvs без сервера и получения с него данных вообще шагу ступить не может.
> Все сырцы, все поколения иксов, все порты, все варианты веб-сайта - в общем, полная
> история всего проекта. Могу иметь к ней доступ без наличия сети.Это круто, только в git это делается 1 командой, в систему не вкрячивается ничего кроме самого гита, а сам гит - быстрый как пoнос.
> Я не вижу тут проблемы.
Ну еще бы. Ты же не разработчик. А вот если вопрос в том чтобы разрабатывать и поменьше греть себе мозг закидонами тулзов и поменьше ожидать их реакции - вот тут git просто unbeatable.
>> Как git работает с AUR, сколько места оно занимает и как "быстро"
>> работает - я видел...
> А я видел как git разворачивает проект размером с линевый кернель за
> несколько секунд.- вот так, из буханки хлеба, двух карандашей и катушек ниток можно за одну минуту собрать модель треллейбуса.
один вопрос, а нахрена?такое впечатление, что у расписывающих прелести git vs что-то и как жить без него, шизофренический распад представлений о мире. =)
> - вот так, из буханки хлеба, двух карандашей и катушек ниток можно
> за одну минуту собрать модель треллейбуса.
> один вопрос, а нахрена?Затем что
1) Я иногда даю себе труд попытаться *локализовать* баги на которые натыкаюсь. Да, git умеет такую мелкую но симпатичную плюшку как git bisect. При помощи svn нечто такое делать вообще на мало-мальски большом проекте отcтой неимоверный. И любой кто хоть минимально относится к разработке софта должен это бы уже усвоить. Хотя, несомненно, можно и не использовать эффективные инструментарии отлова багов. Любое дело можно делать нудно, сложно и печально, стоит только захотеть.
2) Я таки билдую по разным причинам те или иные проекты и иногда так бывает что например в новой версии программы посадили жирный баг. Будет здорово, если будет можно отмотать на исправную версию пока причастные врубаются где они там лоханулись и лыжи все-таки будут ездить. При том сейчас, а не через неделю. И не скачивая половину интернета еще раз.> без него, шизофренический распад представлений о мире. =)
Всего лишь приступ капитанинга, не более.
> даю себе труд попытаться *локализовать* баги на которые натыкаюсь.попробуйте воспользоваться редактором и отладчиком.
Проект FreeBSD отключил инфраструктуру обеспечения работы CVSup от системы жизнеобеспечения//fixed
чо бы dvcs не использовать? потому что в проклятом ляпиксе уже dvcs?
Потому что ИМ пока не нужно. У них модель разработки другая.
> Потому что ИМ пока не нужно. У них модель разработки другая.У них модель разработки именно такая. Но вы правы, git им не нужен.
>> Потому что ИМ пока не нужно. У них модель разработки другая.
> У них модель разработки именно такая. Но вы правы, git им не
> нужен.ну ладно, другая, но у тебя тоже один гит в голове?
> ну ладно, другая, но у тебя тоже один гит в голове?Теперь то же самое, но по-русски.
Какая проблема использовать гит централизованно?
Не могут выбрать между Mercurial и Git. :))
Одни орут: "Ставьте Git!!! Его все молодые и горячие парни используют!!". Другие тихонечко шепчут: "Есть же куда более надёжный Mercurial, у которого вся история правок как на ладони".
> Не могут выбрать между Mercurial и Git. :))Когда переходили на SVN множество разработчиков предлагало git, но ни один - mercurial (но победил всё-таки SVN). Ты же бздун, сам этот тред видел.
А чем их CVS-то не устроил?
Мы с парнями годами храним файлы в архивах по дате, заказчики довольны, аптайм 100%, скоро дочке свадьбу шикарную спразднуем.
> Мы с парнями годами храним файлы в архивах по дате, заказчики довольны,
> аптайм 100%, скоро дочке свадьбу шикарную спразднуем.А вон те чуваки до сих пор на деревянной телеге с лошадью на дорогу выезжают. Свадьбы они тоже празднуют, вероятно.
> А чем их CVS-то не устроил?Вы наверное о разных VCS только краем уха слышали? Пора бы уже что-нибудь освоить, а потом сможете и сравнить с CVS, чтобы таких глупых вопросов не задавать.
>> А чем их CVS-то не устроил?
> Вы наверное о разных VCS только краем уха слышали? Пора бы уже
> что-нибудь освоить, а потом сможете и сравнить с CVS, чтобы таких
> глупых вопросов не задавать.Ну, я о разных VCS слышал. У меня даже fossil-репозиторий поднят, не говоря о hg и git, коих у меня наличествует. Про svn тоже знаю: правда, новых svn, которые без .svn в каждом каталоге - не видел...
FreeBSD, конечно, в разы больше OpenBSD, но для OpenBSD я ничего удобнее CVS на данный момент представить не могу. А замена CVS на SVN - это и замена всей инфраструктуры, и, вероятно, перевод всех пользователей и период адаптации. Или у FreeBSD совсем другая иерархия?
> Ну, я о разных VCS слышал. У меня даже fossil-репозиторий поднят, не
> говоря о hg и git, коих у меня наличествует. Про svn
> тоже знаю: правда, новых svn, которые без .svn в каждом каталоге
> - не видел...То есть якобы пользуетесь всем, на деле ничем. Понятно.
> FreeBSD, конечно, в разы больше OpenBSD, но для OpenBSD я ничего удобнее
> CVS на данный момент представить не могу. А замена CVS на
> SVN - это и замена всей инфраструктуры, и, вероятно, перевод всех
> пользователей и период адаптации. Или у FreeBSD совсем другая иерархия?Такая же. Пользователи переехали без проблем, всё-таки, во-первых, перелезть с убогого CVS на что угодно хотели все, во-вторых, был написан svnup для замены cvsup, так что разницы никто не почуствовал. C git в этом плане было бы сложнее.
>C git в этом плане было бы сложнее.С чего бы это? В DFBSD гит из коробки уж сто лет как. И для системы, и для портов. И ничего им не мешает, ни в каком месте.
> С чего бы это? В DFBSD гит из коробки уж сто лет
> как. И для системы, и для портов. И ничего им не
> мешает, ни в каком месте.У них нет ни пользователей ни самописных утилит - в таком состоянии они могут со следующим релизом подсунуть вместо DF винду - никто ничего не заметит.
> Ну, я о разных VCS слышал. У меня даже fossil-репозиторий поднят, не
> говоря о hg и git, коих у меня наличествует.При том у всех поди целый 1 коммитер - сам буратина. Так прямо сплю и вижу могучий опенсорсный процесс во главе с нашим деревянным лидером.
> А чем их CVS-то не устроил?Очень неполный список: https://wiki.freebsd.org/VCSCvsProblems
> чо бы dvcs не использовать? потому что в проклятом ляпиксе уже dvcs?да подожди ты лет десять-пятнадцать, и всё будет.
> да подожди ты лет десять-пятнадцать, и всё будет.Ну так как раз напишут свой урезанный и глючный вариант. Зато под BSDL!!!1111
да не, тут не лицензия, тут реально old farts не въезжают. для них dvcs — до сих пор равнозначно анархии.
> них dvcs — до сих пор равнозначно анархии.А оно в каком-то роде анархия и есть. В своем локальном закутке можно извращаться как душе угодно. И (в отличие от SVN/CVS!) - за всю эту ораву коммитов никто и слова не скажет. При этом я смогу нормально трекать мои коммиты и по ним мотаться.
А то что остальные совсем не обязаны брать мои коммиты в свои деревья - второй вопрос :). И то что они добровольно решили считать Торвальдса координатором усилий - тоже отдельный вопрос. Его в общем используют в этом качестве потому что он делом доказал что может это и может это хорошо. Что более забавно - диктатор сам же и напрограмил тул для того чтобы диктатура не могла быть технически эффективной, что весьма забавно :). У всех равноправные репы, а кто и почему служит точкой обмена наработками и координации - сугубо вопрос договоренностей и желания тех или иных людей взаимодействовать.
да это-то понятно. я в данном случае имел в виду «анархия как что-то плохое».но вообще я считаю, что очень рано они такие миграции делают. есть же провереный временем rcs, зачем вот эти прыжки?
Столько споров и о таком вопросе!
Скажите, неужели всем нравятся блондинки? [да простят меня девушки, если таковые имеются] Сильно сомневаюсь, иначе другие цвета волос уже наверняка стали бы слишком уж нечастыми.[не очень хорошо разбираюсь в генетике и наследственности, посему прошу сильно не гневаться знатоков оной науки] Так может любителям блондинок(к примеру гита) не стоит так уж написать на любителей брюнеток(меркуриала) и шатенок(свн), равно как и в обратную сторону?
P.S. Все совпадения цвета волос девушек из примера с приведёнными СКВ случайны)
пример некорректный. ответ на вопрос «почему?» — «купи метлу».
> пример некорректный. ответ на вопрос «почему?» — «купи метлу».Отлично аргументированная позиция) А главное-насколько полна миролюбия, как призывает к единению приверженцев свободного ПО!
ты меня с кем-то попутал: лично мне в «приверженцах» дураки не нужны.
> ты меня с кем-то попутал: лично мне в «приверженцах» дураки не нужны.Сам ты "попутал". Кому ты нафиг нужен, яркий пример глухого закостенелого мышления типа "...кто думает отлично от меня-дурак!".
Вы наверное ren-tv любите смотреть.
> Вы наверное ren-tv любите смотреть.Вы, наверное, не знаете о существовании зяпятых.
> Вы, наверное, не знаете о существовании зяпятых.Ты ещё к моей национальности придерись. Если уж слил, лучше помалкивай.
>> Вы, наверное, не знаете о существовании зяпятых.
> Ты ещё к моей национальности придерись. Если уж слил, лучше помалкивай.Твоя национальность-аноним неизвестный. Как к оной придраться-то, дубинушка?
А слил я тебя в унитазе, так что помалкивай там на днище сам, да не булькай, ато забрызгаешь ещё! )))
> Сам ты "попутал". Кому ты нафиг нужен, яркий пример глухого закостенелого мышления
> типа "...кто думает отлично от меня-дурак!".А вы, я сотрю, наоборот любитель дураков на трон сажать.
>> Сам ты "попутал". Кому ты нафиг нужен, яркий пример глухого закостенелого мышления
>> типа "...кто думает отлично от меня-дурак!".
> А вы, я сотрю, наоборот любитель дураков на трон сажать.Сотрю? Это ты ластиком сотрюшь? )
Чем дальше, тем большим дурачком ты себя выставляешь, отвечая не по делу. Вон снизу привели адекватную аналогию - есть что на неё ответить, или глистом тут будешь извиваться, обсуждая грамматику да пунктуацию?
> Чем дальше, тем большим дурачком ты себя выставляешь, отвечая не по делу.
> Вон снизу привели адекватную аналогию - есть что на неё ответить,
> или глистом тут будешь извиваться, обсуждая грамматику да пунктуацию?Хочешь убедить меня посадить тебя, дурака, на трон? ) Знаешь, как пишется слово "заколебёшься"? )
Ха-ха, пришёл как славный примирятель во славу "единения приверженцев свободного ПО", а оказался обычным гoвнецом. Ты сам себя уже посадил, и не только на трон, так что гуляй.
> Ха-ха, пришёл как славный примирятель во славу "единения приверженцев свободного ПО", а
> оказался обычным гoвнецом. Ты сам себя уже посадил, и не только
> на трон, так что гуляй.Фу, анонимная какаха, какая же ты отвратная!
Тебе же было сказано не булькать со днища унитаза, или ты в этот момент совершал(а) глубокое погружение для набора очередной порции фекальных масс, которые ты тут выплёскиваешь из своего мерзотного отверстия, которое гордо именуешь ртом? Как же тебя смыть-то? Ни в какую не тонешь! )))
> Фу, анонимная какаха, какая же ты отвратная!
> Тебе же было сказано не булькать со днища унитаза, или ты в
> этот момент совершал(а) глубокое погружение для набора очередной порции фекальных масс,
> которые ты тут выплёскиваешь из своего мерзотного отверстия, которое гордо именуешь
> ртом? Как же тебя смыть-то? Ни в какую не тонешь! )))Покажи пожалуйста ещё своей натуры.
>> Фу, анонимная какаха, какая же ты отвратная!
>> Тебе же было сказано не булькать со днища унитаза, или ты в
>> этот момент совершал(а) глубокое погружение для набора очередной порции фекальных масс,
>> которые ты тут выплёскиваешь из своего мерзотного отверстия, которое гордо именуешь
>> ртом? Как же тебя смыть-то? Ни в какую не тонешь! )))
> Покажи пожалуйста ещё своей натуры.Не дождёшься)))
> Чем дальше, тем большим дурачком ты себя выставляешь, отвечая не по делу.
> Вон снизу привели адекватную аналогию - есть что на неё ответить,
> или глистом тут будешь извиваться, обсуждая грамматику да пунктуацию?Сам себя не похвалишь-никто не похвалит, да? )) Как-то не оценивают люди твою аналогию, что ты снизу приводишь, да сам хвалишь)))
Правильная аналогия такая: есть девушки, старухи и резиновые бабы. Есть жирные закомплексованные зaдроты, которые знакомиться с девушками банально боятся, поэтому живут с резиновыми бабами, ну или мамами, и что-то ещё пытаются доказывать всем остальным, которые гуляют с девушками.