Компания Google объявила (https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg) о переводе инфраструктуры разработки языка программирования Go на систему управления исходными текстами Git и платформу совместной разработки GitHub. На днях проекту Go исполнилось пять лет, во время основания проекта была выбрана система Subversion, после чего последовал переход на Perforce, а затем и на Mercurial, из-за необходимости интеграции с существующей системой рецензирования кода. За это время мир изменился и Git занял прочную позицию лидера. Большинство участников сообщества Go используют Git и GitHub для своего кода. Проблемы с системой рецензирования остались в прошлом, поэтому теперь ничто не сдерживает миграцию проекта на Git.
После миграции на Git в качестве системы рецензирования будет использована система Gerrit (http://code.google.com/p/gerrit/), которая уже применяется для кода платформы Android. Миграция на Git начнётся вскоре после релиза 1.4, намеченного на начало декабря. Выпуск 1.5 уже будет сформирован и размещён на GitHub.
URL: https://news.ycombinator.com/item?id=8605204
Новость: https://www.opennet.ru/opennews/art.shtml?num=41059
Вот читал несколько статей о преимуществах других систем над GIT, но кроме каких-то ускоспециализированных вещей вроде, когда нужно еще синхронизировать графику/чертежи и прочую не текстовую ерунду, разумных аргументов не видел.Смысл вообще для новых проектов использовать не GIT?
Поступки, порой, лишены смысла. :-)Но всё-таки. Если, к примеру, провести аналогию с ядром: есть linux, а есть другие *nix подобные ядра. И причины не использовать linux тоже есть.
"Никто не знает гит". В том смысле, что он можный, но понимать - понимают его ой как далеко не все. Получаются ... с гранатой. :(
*мощный
Так по минимуму его освоить не сложнее чем любую иную VCS, а продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый.
> Так по минимуму его освоить не сложнее чем любую иную VCS, а
> продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый.Ну так мерж, это как бе важная часть даже для базового использования, не? Или что вы имели ввиду?
Реально базовое пользование, на мой взгляд, вот такое:
* pull
* checkout
* add
* commit
* pushcheckout может быть опциональным. А merge будет делать "специалист".
Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету.
> Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету.Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.
Я вот видел как-то раз закоммиченные неразрешённые конфликты..)
> Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист".Это для слияния в subversion нужен еще какой специалист! Хотя система-то попроще будет.
> раз для базовой функциональности - слияния, требуется "специалист"Врядли вы хотите чтобы это вам делали дизайнеры и прочие ГСМщики, которые пару действий заучить еле могут. От таких - только коммиты с материалом, не более. Люди разные бывают...
> Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.
При правильном подходе merge можно вынести на плечи тех кто понимает что он делает. Если обезьянка совсем дерево - вы врядли хотите после такой обезьянки мержи себе в проект.
А так git вполне логичная штука. Если не страдать гуманитарным складом ума с полным непониманием рабочих процессов и принятых в распределенных командах подходов.
> При правильном подходе merge можно вынести на плечи тех кто понимает что
> он делает. Если обезьянка совсем дерево - вы врядли хотите после
> такой обезьянки мержи себе в проект.Merge - это часто требуемая на местах функциональность, которую невозможно "переложить на плечи специалиста".
Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, с github'овским master'ом. Т.е. либо git clone ... и ручное внесение своих изменений, либо merge. Чтобы было проще, синхронизироваться нужно раз в день-два. А ведение отдельной ветки до pull-request'а - минимум неделя.
И что - каждый день звать хозяина github'а с просьбой о помощи? :-)
> Merge - это часто требуемая на местах функциональность, которую невозможно "переложить
> на плечи специалиста".Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. Которые могут подогнать полезный проекту материал, но напрочь не технари и тем более не программисты. Я полагаю что таким людям лучше не проводить мерж ни в какой системе контроля версий, во избежание факапа лишний раз.
> Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно,
> с github'овским master'ом. Т.е. либо git clone ... и ручное внесение
> своих изменений, либо merge.А чем вам не нравится git pull из мастера, если уж оно надо? Мерж потребуется только при конфликтах, а поскольку дизайнеры, техписы, переводчики и прочие манагеры код трогать вообще не должны, конфликт свидетельствует или о каком-то грубом косяке со стороны такого индивида, или о том что PM пролошился и разные люди два раза работали над одним файлом типа рисунка, что заведомо кривая ситуация, иррелевантно к vcs. А в нормальном виде, покуда нет грубых нарушений воркфлоу - такие люди просто не должны налетать на конфликты и нужду мержа. Меньше проблем всем остальным.
> Чтобы было проще, синхронизироваться нужно раз в
> день-два. А ведение отдельной ветки до pull-request'а - минимум неделя.Дизайнер или техпис врядли сможет сделать мерж нормально. Как операцию. Независимо от VCS. Поэтому этим должны заниматься другие, во избежание. И таким людям кстати совершенно не обязательно синхриться с мастером раз в пять минут - сделали фичу да выкатили пулл реквест. Остальное вообще не их дело.
> И что - каждый день звать хозяина github'а с просьбой о помощи? :-)
Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.
> Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов.А зачем они вообще должны туда лезть-то? Merge должен делать человек, понимающий в предмете в первую очередь. Если это статья - редактирующий статью, если код - редактирующий код.
> А чем вам не нравится git pull из мастера, если уж оно надо?
Если в мастере произошли изменения в тех же файлах, что ты правил, хочешь-нехочешь, а придётся синхронизировать. Ну и pull-request лучше, всё-таки, делать чистый.
> Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.
Если несколько переводчиков работают над одним текстом, всунутым в VCS, им придётся делать merge. И при этом желательно ничего не ломать.
> Merge должен делать человек, понимающий в предмете в первую очередь.Совершенно не обязательно, ибо понимание предмета != умение делать технически сложные и достаточно ответственные операции. Технические умения ГСМщиков обычно "не очень" и с компьютерами они "на Вы". Получать мерж после таких индивидов может быть достаточно чреватой идеей. Хоть я и допускаю мысль что часть из них можно научить этому, это уже достаточно индивидуально. А в случае какого-нибудь дизайнера нужда выполнять мерж вообще означает какой-то факап в рабочем процессе.
> Если в мастере произошли изменения в тех же файлах, что ты правил,
...то в случае таких ГСМщиков это обычно означает продолб в рабочем процессе.
> Если несколько переводчиков работают над одним текстом, всунутым в VCS,
> им придётся делать merge. И при этом желательно ничего не ломать.Если честно, на практике я ни разу не встречал ситуации чтобы несколько переводчиков лопатили 1 файл. Во первых, нормальный переводчик стоит денег и поэтому даже в очень большой и крутой конторе их обычно спасибо если 1-2 человека. В опенсорсных проектах может быть и поболее. А может и не быть. Но тут есть во вторых. Во вторых, обычно работа такого плана разбита на юниты вменяемого размера которые может лопатить по человеку на файл, не задевая друг друга. Так чтобы Войну и Мир сразу двутомником переводили как 1 файл - такого я попросту никогда не видел, так никто не делает. А те кому ну просто крындец как надо много возиться с переводами программ - иногда используют узкоспециализированный онлайн сервис Transifex. Но для большинства случаев это как-то оверкилл.
Наверно не мерж, а разруливание конфликтов - так это везде повод для паники.
> Наверно не мерж, а разруливание конфликтов - так это везде повод для
> паники.А я не знаю почему Vkni возомнил что это в других VCS как-то проще.
> Наверно не мерж, а разруливание конфликтов - так это везде повод для
> паники.Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из базовой функциональности git (см. комменты выше).
Какое может быть "позвать специалиста", если синхронизировать с github'овским мастером нужно раз в день-два, а разрабатывать свою ветку до pull-request'а неделю? :-)
> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из
> базовой функциональности git (см. комменты выше).А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж правильно и ничего при этом не сломать. Хоть там в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали иные люди. Которые понимают что это такое и как работает. И вполне можно сделать так что индивиду не придется ничего мержить пока он пилит свою фичу. А если индивид окажется не тyпым в техническом плане - можно обучить его основам и поднять эффективность взаимодействия с оным, aka получив возможность совместно работать над одними и теми же файлами. Но это катит только для текстовых файлов (как вы себе представляете мерж картинки со стороны VCS?) и не со 100% индивидов.
> Какое может быть "позвать специалиста",
Если человек не может делать мержи - его налет на нужду это делать должен стало быть исключением а не правилом. Это несколько лимитирует возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и может сделать взаимодействие менее приятным чем могло бы быть.
> если синхронизировать с github'овским мастером нужно раз в день-два,
> а разрабатывать свою ветку до pull-request'а неделю? :-)Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо часто синхриться и тем более что-то мержить. Они по идее вообще ни с кем конфликтовать не должны и если это случается - где-то в воркфлоу порылся нехилый косяк.
> И вполне можно сделать так что индивиду не придется ничего мержить пока
> он пилит свою фичу.Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce).
> Но это катит только для текстовых файлов (как вы
> себе представляете мерж картинки со стороны VCS?) и не со 100%
> индивидов.Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Кстати, это не сделано ли во всяких Google Docs?
> Если человек не может делать мержи - его налет на нужду это
> делать должен стало быть исключением, а не правилом.Угук. Только далеко не всегда это возможно, поэтому исключение очень легко может перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён.
> Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами
Если процесс сделан так, то git pull сделает всё сам. Это - идеал, но не всегда возможный идеал.
> Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce).На самом деле очень зависит от людей и того над чем они работают. Поэтому каких-то абсолютно универсальных рецептов не бывает. У нормальных проектов есть некий запас гибкости для того чтобы провзаимодействовать с неким ценным кадром, желательно как можно меньше напрягая остальных. Собственно, хороший руководитель проекта кроме всего прочего может такие вещи утрясти до формата когда процесс идет, явных продолбов не случается и команда не исходит на мат от кривых инструментов и подходов.
> Тут хорошая тема поднимается - как делать VCS для нетекстовых данных.
Ну да, это довольно отдельная тема. И я не уверен что отложенное совместное редактирование например картинок вообще эффективно. Вот толпой отредактировать картинку в реалтайм - может и прокатит, но такие процессы имеют свойство скатываться в бардак который очень бесит участников, если индивиды не идеально скоординированны. Проверено на сервисе совместного редактирования текстов. Очень бесит когда кто-то буквально под твоим пером переписывает у тебя текст на полуфразе и ты остаешься в обломе.
> Кстати, это не сделано ли во всяких Google Docs?
Не знаю, я ими не польуюсь. А что, они умеют мерж допустим картинок из нескольких источников в одну? И как это выглядит? Нет, я понимаю как посчитать бинарный дифф пары битмапов, но он совершенно не обязан оказаться именно тем что все хотели, а как-то более гранулярно выбирать что вот тут мы берем пикселы от Васи, а тут от Пети - выглядит не очень простой в реализации затеей и я что-то не уверен что таким vcs должен заниматься.
> перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён.
Да там и нет никакой ракетной науки. Просто некоторые ГСМщики настолько "на Вы" с компьютером что будет лучше если они не будут это делать и это будет именно исключением для них.
> Если процесс сделан так, то git pull сделает всё сам. Это -
> идеал, но не всегда возможный идеал.Ну ок, у меня одна картинка а в мастере другая. При том обе отличаются от общего предка. И чего должен сделать автомат? Врубить AI и вместо участников проекта решить какая же картинка правильная? Ну если там такой крутой AI, может команду уже пора уволить? Если AI может такое решение принять - он пожалуй и картинки нарисовать сможет и код напишет :).
Как по мне, мердж в гите прост, и уж явно удобнее чем в свн, к примеру. А для тех кто не может осилить набор команд и их параметры есть гуевыые или встроенные в IDE клиенты.
> А для тех кто не может осилить набор команд и их параметры...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не вяжет, а вы ему ответственную работу?!
>> А для тех кто не может осилить набор команд и их параметры
> ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не
> вяжет, а вы ему ответственную работу?!Наверно, в Git и SVN/CVS операция merge — ответственная работа.
В hg про merge должен быть в курсе каждый разработчик, который коммитит в центральный репозиторий. Иначе он не сможет запушить свои изменения, конфликтующие с теми, которые уже есть в репозитории и сделаны до него.
Для успешного разрешения конфликта в hg нужно воспользоваться операцией merge на месте — провести слияние сначала в локальном репозитории, протестировать слияние, закоммитить, а потом уже пушить результат в центральный репозиторий.
То есть понимание работы операции merge является одним из основных особенностей работы в команде с hg. Без этого знания разработчикам на местах делать будет просто нечего — они не смогут обмениваться единым кодом.
Знакомьтесь, это - изен. Он сегодня делает то же что и обычно - тормозит и затупляет.
Предпочитать какое-либо решение только потому, что оно является самым популярным (лидирующим) — плохой подход, приводящий к централизации, ослаблению конкуренции и укреплению монополий, замедлению развития, уменьшению положительной зависимости между популярностью и техническим совершенством (если она вообще есть). Ко всему популярному следует относиться с особым подозрением.Я не говорю, что не надо использовать Гит, но уж точно не надо использовать его только потому, что он популярнее других. И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета.
Со всем согласен кроме:> И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета.
На мой взгляд, github во многом упрощает жизнь. И по-хорошему проект лучше просто держать сразу в двух местах (на github и на своём локальном сервере).
всеобщее клеймение штрихкодами на лбу во многом упрощает жизнь, но почему-то немногим это нравится
Во-первых, и что с того? Как это связано с тем, что написал я? Не нравится — не используй. Но критиковать другого за то, что он продублировал свой проект на GitHub и упростил пользователям проекта жизнь — это уже перебор. Ваши проекты-то никто не заставляет на GitHub переносить? Настривайте сколько угодно remote-ов и делайте с ними что угодно.
Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах.SourceForge вы тоже считаете системой штрих-кодов на лбах?
>Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах.Логично. Тогда сделай себе штрихкод на лбу. Это явно удобнее, чем паспорт.
>>Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах.
> Логично. Тогда сделай себе штрихкод на лбу. Это явно удобнее, чем паспорт.Не эстетично. И повторюсь:
> Как это связано с тем, что написал я? Не нравится — не используй.
Мне не нравится штрих-код на лбу. Не буду использовать данную идею.
> Во-вторых, мы и так таскаем паспорта.Я, лично, хожу с паспортом по СПб крайне редко. Чаще всего, никакого удостоверения личности у меня нет.
> удостоверения личности у меня нет.Полисмены just in case будут недовольны и могут при случае задержать до выяснения. Если, конечно, полисмены в обозримом радиусе есть...
> Полисмены just in case будут недовольны и могут при случае задержать до
> выяснения. Если, конечно, полисмены в обозримом радиусе есть...Практика показала, что для меня этот случай крайне маловероятен. Машина собьёт скорее.
> Практика показала, что для меня этот случай крайне маловероятен. Машина собьёт скорее.Ну и ок :). На самом деле я тоже далеко не всегда беру с собой паспорт по тем же причинам. А желающим вытатуировать штрихкод - с удовольствием поможет скайнет :).
Сообщество разработчиков Go выбрало наиболее удобное для себя решение. Это выбор не навязанный, а свободный. К монополии такие решения приводить не могут. Никто не запрещает использовать лучшие, по каким-либо параметрам, системы.
> И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета.Бред. К централизации Интернета это отношения не имеет совершенно.
Используя не лучшие решения ты поощряешь посредственность и теряешь в собственной производительности.
Ненавязанный, свободный выбор может приводить к монополии. Вот пример: есть две компании с примерно одинаковыми (конкурирующими) продуктами, продающимися, ясен пень, по примерно одинаковым ценам. Внезапно первая компания устраивает демпинг и начинает продавать свой продукт по цене в 10% от предыдущей. Вторая компания теперьа) может порадоваться, что они устроили своим клиентам lock-in, и тем даже теперь невыгодно сменять используемый продукт; вторая компания остается на плаву— нет, погодите, мы же рассматриваем "свободный и ненавязанный выбор", верно? Значит, этот вариант не проходит;
б) может потерять всех пользователей, потому что как она упросит платить клиентов за такой же продукт вдесятеро дороже? Выбор-то у клиентов свободный и ненавязанный. Что за этим следует — известно, первая компания останется на рынке в одиночестве и сможет воспользоваться своим новым положением.
в) может устроить ответный демпинг. Ну, кто-то не выдержит и разорится первым, а оставшаяся компания — см. выше.
Вот поэтому (а так же и потому что можно держать бесплатно закрытые репы) я и использую bitbacket.org))
> bitbucket.orgКонечно же :)
смысл использовать mercurial:* встроенный предохранитель от переписывания опубликованной истории
* shared mutable history (в разработке, но пользоваться уже можно)
* сам факт того, что разработчики занимаются не только исправлением ошибок и мелкими доводками интерфейса
* ну и да, искаробочный плагин версионирования блобов
> смысл использовать mercurial:
> * встроенный предохранитель от переписывания опубликованной историиЧто это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь?
> * shared mutable history (в разработке, но пользоваться уже можно)
Это что-то для избегания ssh+vi?
> * сам факт того, что разработчики занимаются не только исправлением ошибок и
> мелкими доводками интерфейсаВ git тоже. Особенно, когда заявили о проблеме производительности на крайне больших деревьях.
> * ну и да, искаробочный плагин версионирования блобов
Как это работает? Я изменил картинку — что сделает этот plugin?
>> смысл использовать mercurial:
>> * встроенный предохранитель от переписывания опубликованной истории
> Что это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь?поясню на примере http://www.mail-archive.com/dri-devel@lists.sourceforge... — это когда airlied говорит `git rebase myfeature 123456`, а ему «can't rebase public changesets». а он такой «хмм, а откуда там public changesets?» и смотрит в git log. а в логе и правда чужие коммиты. и он такой «ох ты блин точно, git rebase myfeature 3456789». и всё в порядке, а треда выше по ссылке никогда бы не появилось.
>> * shared mutable history (в разработке, но пользоваться уже можно)
> Это что-то для избегания ssh+vi?нет. http://mercurial.selenic.com/wiki/ChangesetEvolution
>> * сам факт того, что разработчики занимаются не только исправлением ошибок и мелкими доводками интерфейса
> В git тоже. Особенно, когда заявили о проблеме производительности на крайне больших деревьях.собссно junio hamano принимает практически любые патчи, кроме меняющих UX в любую сторону.
>> * ну и да, искаробочный плагин версионирования блобов
> Как это работает? Я изменил картинку — что сделает этот plugin?запишет картинку в отдельный каталог. а при мерже просто спросит «этот файл поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффы, которые всё равно не имеют смысла.
>>> смысл использовать mercurial:
>>> * встроенный предохранитель от переписывания опубликованной истории
>> Что это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь?
> поясню на примере http://www.mail-archive.com/dri-devel@lists.sourceforge...
> — это когда airlied говорит `git rebase myfeature 123456`, а ему
> «can't rebase public changesets». а он такой «хмм, а откуда там
> public changesets?» и смотрит в git log. а в логе и
> правда чужие коммиты. и он такой «ох ты блин точно, git
> rebase myfeature 3456789». и всё в порядке, а треда выше по
> ссылке никогда бы не появилось.Ок, верю, что ему-то это может и надо.
>>> * shared mutable history (в разработке, но пользоваться уже можно)
>> Это что-то для избегания ssh+vi?
> нет. http://mercurial.selenic.com/wiki/ChangesetEvolutionАналогично.
>>> * ну и да, искаробочный плагин версионирования блобов
>> Как это работает? Я изменил картинку — что сделает этот plugin?
> вместо того, чтобы рассчитывать диффы, которые всё равно не имеют смысла.А git рассчитывает diff-ы для бинарных файлов?
> А git рассчитывает diff-ы для бинарных файлов?Дельту он попробует посчитать. Это не текстовый дифф, конечно. Может получиться а может и нет - зависит от устройства файлов. На практике же - я спокойно коммитил пачку графики в гит и никто не жаловался. Просто не надо это делать совсем уж безбашенно.
А попытки сделать vcs удобной для невменяемых обезьян - сделают ее неудобной для всех остальных. Чего ради я должен греть мозг вопросами где брать файл? У меня есть рабочее дерево проекта и я разложил файл в правильное место иерархии проекта. Вот там он и должен жить по логике вещей.
> ... а при мерже просто спросит «этот файл поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффыэто же каким упоротым нужно быть чтобы гнать такой бред
> rebase myfeature 3456789». и всё в порядке, а треда выше по
> ссылке никогда бы не появилось.Вообще-то для начала у него там подробно расписан воркфлоу который он хочет видеть и там кроме всего прочего - отсутствие незапланированных приколов когда некто что-то делал с чужим кодом. Вообще, чтобы ребэйзить чужой код - надо страдать конкретным донкихотством и считать себя самым умным на планете.
Так что я так подозреваю что то чего ты хочешь - может привести лишь к неудачным воркфлоу, когда некто берет на себя слишком много и делает это тихой сапой. И даже отсутствие потерь истории при этом - не делает сильно лучше, ибо проблема - сам такой воркфлоу, когда Вася зачем-то пускает свои грязные лапы в фичу Пети которую он может быть впервые в жизни видит, что-то с ней делает и прочее. В результате Петя как минимум уже не может отвечать за свою фичу - ее Вася от большого ума перепахал. Без спроса.
> собссно junio hamano принимает практически любые патчи, кроме меняющих UX в любую
> сторону."Автомобиль Форд может быть любого цвета, при условии что он черный" :).
> поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффы,
> которые всё равно не имеют смысла.Дифф может иметь смысл а может не иметь. В рамках проекта удобно универсально работать с проектом в рабочем дереве и не греть себе мозг вопросом "откуда брать файл". Из дерева проекта. Нафиг он мне еще в пяти местах? Поэтому лично я вполне себе коммитил измененную графику в гит, это всех устраивало и размер репы оставался вменяемым. Ну да, лист A4 @ 600DPI коммитить раз в пять минут конечно глупо. Но это про common sense, а не технологии...
> * встроенный предохранитель от переписывания опубликованной историиЭто вообще как? И почему это - фича? Гит вроде делает логичнее просто некуда - показывает все коммиты которые есть. Что и зачем надо с историей делать? Что еще за предохранители? От чего они предохраняют? Не очень понимаю - ремотный коммит ничего моему коммиту сделать и так не может вроде. От чего предохраняться то?
Go, go, go ... А он может так же классно мозг взорвать как и C++?shared_ptr<double> pd;
double *p_reg = new double;После чего, следующие строки не одно и тоже!
shared_ptr<double> psahred = p_reg;
shared_ptr<double> pshared(p_reg);Если нет, то значит от него нельзя получить интеллектуального оргазма и следовательно, язык, он не интересен :)
> Go, go, go ... А он может так же классно мозг взорвать
> как и C++?
> shared_ptr<double> pd;
> double *p_reg = new double;
> После чего, следующие строки не одно и тоже!
> shared_ptr<double> psahred = p_reg;
> shared_ptr<double> pshared(p_reg);
> Если нет, то значит от него нельзя получить интеллектуального оргазма и следовательно,
> язык, он не интересен :)В гамаке и ластах, да не удобно
Можно и икс себе отрезать.>shared_ptr<double> pd;
>double *p_reg = new double;что уж, пиши сразу void *p = (void *)0x1233425; (int)*p = 1; авось повезет
не, ну вы то ерундо то написали
это одинаковая ерунда, что в твоем примере, что в моем. Учи c++
Ты то пальцем в небо тыкнул, туда байты инта начал загонять, тут понятно что будет бред, а я то говорил к тому, что в плюсах сплошные неявные строгие правила. В данном случае, что должно быть явное оределение.
> авось повезетI'm feeling luSegmentation fault
Конструктор shared_ptr, который принимает указатель, нужно вызывать явно (explicit). Это является защитным механизмом, чтобы программист понимал, что shared_ptr становится владельцем этого указателя и освободит его сам.
интеллектуального оргазм от с/с++ достигается на таком коде:
#ifndef OPENSSL_NO_HEARTBEATS
int tls1_process_heartbeat(SSL *s){
unsigned char *p = &s->s3->rrec.data[0], *pl;
unsigned short hbtype;
unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
Ручное управление памятью, все дела. Зато быстро.
> Ручное управление памятью, все дела. Зато быстро.Сдуру можно и х... сломать. И root cause тут не сишечка, а
1) Переусложненный протокол с кучей легаси и костылей.
* Для начала, фича просить у ремоты энное количество байтов - не должна была существовать, даже в проекте. Ну и багов в ней - соответственно, быть не должно.
* А вон тут соседняя атака - с буферами ничего не делает вообще. MITM просто даунгрейдит протокол с TLS'а до SSLv3 и потом радостно вскрывает древний и слабый вариант протокола. И ничего вы с этим отказом от управления памятью не сделаете.
2) Как известно, сдуру можно и х... сломать и в криптографии автоматическое управление памятью - последнее что может помочь криптографу. Ключи должны изничтожаться предсказуемо, etc. Без этого будет много неочевидных ламоватым кидизам но от того не менее опасных в плане утечки ключей дыр. Ключ должен существовать ровно столько сколько он требуется и на этом пути GC с отложенной сборкой может очень сильно нагадить. И вообще, идея использовать криптографическую либу от тех кто не может даже памятью управлять - очень сомнительна. А сколько там тогда багов в алгоритмах криптографии и обвязке?
3) У OpenSSL дурное апи и дурной код. Ее авторы вообще не криптографы. Поэтому не так уж принципиально какой ЯП они возьмут. Сильно безопаснее не станет. Наворачивание хитрозадых конструкций на сях лишь немного дополняет эту картину. И не более того. А вовсе и не перекраивает весь ландшафт.
Ямщик, не гони.sp_test.cpp: In function ‘int main()’:
sp_test.cpp:10:30: error: conversion from ‘double*’ to non-scalar type ‘std::shared_ptr<double>’ requested
shared_ptr<double> psahred = p_reg;Конструктор shared_ptr объявлен explicit как раз, чтобы не было неявного преобразования.
такие вещи надо писать на ржавчине, а не на плюсах :)
> Go, go, go ... А он может так же классно мозг взорвать как и C++?Это язык для продакшнов, у него задачак как раз не взрывать мозг даже на сложных алгоритмах — всё записывается немногочисленными простыми конструкциями. А для интеллектуальных оргазмов, вперёд в Хаскель (Лисп, Форт, Брайнфак...).
тут никакого взрыва мозга нет.
ещё в одном, отдельно взятом государстве наступил коммунизм...
А теперь вопрос для размышления:"А ПОЧЕМУ НЕ НА code.google.com ???"
Потому что оно самое неудобное из всех хостингов и, можно сказать, сдохло.
Вот лишь бы ляпнуть.Как ты думаешь, где он хостился до этого (всё ещё пока хостится)?
А таки давно понятны толстые намёки гугла на будущее code.google.com
Просто с этой платформой нельзя как со всякими рсс-читалками за пару месяцев закрыть и никаких последствий.Готовят из далека, чтобы адекватные потихоньку оттуда съезжали, а новые проекты даже не думали там заводиться.
> Готовят из далека, чтобы адекватные потихоньку оттуда съезжалиАдекватные для начала там никогда и не будут хоститься - достаточно 1 взглядя на интерфейс. Вообще гугл в отличие от мс хотя-бы умеет признавать что схватился за то что им не свойственно и вышла фигня. А мс до последнего впаривает кривой булшит, типа горбатых кирпичей в восьмерке.
>А мс до последнего впаривает кривой булшит, типа горбатых кирпичей в восьмеркечто за горбатые кирпичи? Если речь про плитки, то в десятке они фактически выпилены
Как сделать хорошо?
Просто! Сначала сделай чтоб было хуже, чтоб совсем плохо ... а потом верни всё, как было до этого! :)
(C) M$ Business Strategy Manual.
> что за горбатые кирпичи? Если речь про плитки, то в десятке они
> фактически выпиленыМне если честно уже пофиг - у меня на десктопе и ноуте пингвин и мое DE совершенно не зависит от кучи причуд группы придypков из редмонда. И будет таким какое удобно мне, а не каким-то левым хpeнам.
Как перенесут leveldb с гугль-кода - значит конец гуглькоду пришел. Для меня такой маркер
Ну, значит всёhttps://code.google.com/p/leveldb/
The LevelDB project has moved to https://github.com/google/leveldb
> Просто с этой платформой нельзя как со всякими рсс-читалкамиofftopic: есть отличный проект quiterss, прижился, рекомендую.
> "А ПОЧЕМУ НЕ НА code.google.com ???"Потому что по сравнению с гитхабом он.. мм... как бы это помягче то, без мата? :)
>Потому что по сравнению с гитхабом он.. мм... как бы это помягче то, без мата? :)Эээ... гуёвый?
>> "А ПОЧЕМУ НЕ НА code.google.com ???"
> Потому что по сравнению с гитхабом он.. мм... как бы это помягче
> то, без мата? :)ничем особо не отличающийся, кроме количества хипстеров?
Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на себя своей массой (чисто популярностью: "у соседа git - у меня тоже будет git"), теперь контроль версий = git.
Разве это плохо?
плохо ли невежество?
> плохо ли невежество?Смотря что пытаются им назвать, а что -- представить как "просвещённость".
> плохо ли невежество?Использование гит != невежество. И да, вас не смущает что вы на опеннет должны идти по именно TCP/IP? А то может вам IPX/SPX симпатичнее? И что постить надо по именно протоколу HTTP? А то мало ли, вдруг вам gopher больше нравится?
К чему это я? А к тому что в сетях и при взаимодействии с другими людьми придется соблюдать некие форматы и протоколы.
> Использование гит != невежество. И да, вас не смущает что вы на
> опеннет должны идти по именно TCP/IP? А то может вам IPX/SPX
> симпатичнее? И что постить надо по именно протоколу HTTP? А то
> мало ли, вдруг вам gopher больше нравится?Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен.
> Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен.1) У IPv6 есть навалом своих проблем. В том числе новых и свежих.
2) Если кто хочет IPv6, его можно получить. Может кривовато, но все-таки.
3) А настоящий next gen на самом деле должен выглядеть в первом приближении как-то так: https://en.wikipedia.org/wiki/Cjdns - заметьте, вменяемые люди не уповают ни на кого и делают из того что есть то что хочется. Наиболее практичный подход.
> Разве это плохо?Плохо.
> Плохо.Не хуже чем необходимость использования IPv4 и HTTP для отправки сообщений на опеннет.
победил как технически более лучшее и удобное решение из доступных альтернатив.
> Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на
> себя своей массой (чисто популярностью: "у соседа git - у меня
> тоже будет git"), теперь контроль версий = git.разработчики FreeBSD смотрят на тебя как на говорящего микроба.