Это так (на их сайте написано, что это «feature of last resort»). Но с subversion вы тоже не сможете работать с другими ревизиями в оффлайне. Другие клоны сделать сможете, но не сможете получить на них ревизию, файлов для которой нет в кэше.
Только на ситуацию мы смотрим с несколько разных сторон. Вы, похоже, работаете в компании, а я в основном работаю с СПО в свободное время. Поэтому CI сервера либо нет, либо это travis, который при всех своих достоинствах будет собирать намного медленнее, чем это возможно на моей машине. Поэтому получать необходимые для сборки файлы из ещё одного репозитория мне не очень удобно. Поэтому я так рекламирую largefiles, несмотря на то, что сами разработчики обозвали её «feature of last resort».
С моей точки зрения это выглядит как проблема в архитектуре git. Мы не можем создать аналог largefiles — мы запретим большие файлы вообще. Выше уже приводили множество примеров, когда большие файлы нужны, причём хорошо бы именно в репозитории (случаев, когда большие файлы в репозитории необходимы ещё не приводили). Я лично никогда бы не стал по собственной инициативе помещать большие бинарные файлы под контроль git (именно git). Но только потому, что у git нет largefiles, а я не хочу ждать лишние минуты, пока бинарники для ненужных версий загружаются, а не потому что я противник помещения больших бинарных файлов под контроль СКВ вообще.
Я расписал все здесь: habrahabr.ru/post/184248/#comment_6406364
Там вы расписали что‐то не так.
Вот этот комментарий, на который я отвечаю, действительно описывает проблему. Но фикс, о котором вы говорите, надо проверить. Для этого ПО надо собрать. Для этого бинарники нужны. Если они не нужны для сборки, то их надо засунуть в другой репозиторий. Вы же не будете возражать, если рядом с этим репозиторием будет лежать другой, к примеру «static_content», с кучей бинарников? Или что фиксы надо проверять?
Это уже всё организационный вопрос. Хранить ненужные бинарники вместе с исходным кодом не нужно. Я, правда, не занимался разработкой для web и потому не могу сказать, насколько эти несколько гигабайт «хлама» могут быть нужны для тестов. Возможно, что вы огорчаетесь зря. Но если я вижу, что человек засунул скомпилированные бинарники, пачку установщиков для всех поддерживаемых систем и все снимки экрана, которые он использует на своём сайте, к исходному коду, то я тоже огорчаюсь. (Правда, таких разработчиков я ещё, к счастью, не видел.)
Да. Система контроля версий, не git. В mercurial с включённым largefiles вы гоняете только хэши бинарников и те версии бинарников, которые вам необходимы в данный момент. В subversion вы тоже гоняете только необходимые версии. У largefiles есть локальный кэш, у subversion вроде тоже (но точно не скажу), поэтому даже необходимые версии может оказаться не нужным гонять.
Другое дело если бинарники не являются необходимыми для сборки. Но это вопрос организации разделения на репозитории, не вопрос того, подходят ли системы контроля версий для хранения бинарников.
// Кстати, с бинарниками и сжатием есть как всегда возможность получить overhead вместо сжатого файла. Так что я даже и не думал говорить о том, что наличие сжатия может сделать конкретную СКВ пригодной для хранения бинарных данных.
Насколько я знаю, в git храняться сжатые blob’ы: полные версии файлов. Никаких дельт. В Mercurial действительно дельты, но есть largefiles, хранящий бинарные файлы отдельно и без дельт. Про subversion не знаю.
Почему? Гонять все версии всех бинарников для каждого клона, конечно, удовольствие маленькое. Но для таких целей есть mercurial с расширением «largefiles», гоняющее только хэши и нужные версии. Надо просто было добавить то же самое в git.
Для того, чтобы убрать эти файлы из репозитория, ограничения в 100 МБ совершенно недостаточно. В таком случае, если ограничение на размер самого репозитория позволяет (а оно позволяет, иначе файлы бы там не лежали), мне было бы проще просто порезать большие файлы с помощью split и собирать обратно на CI сервере нежели использовать хэш и хранить исходные файлы (если, конечно, они тоже превышают данный размер) где‐то ещё.
То есть запретить такие файлы можно. Но максимум, чего вы добьётесь — «заставите задуматься». Во всех случаях хранения таких файлов в git, которые я могу себе представить, может быть использована резка их splitом с последующей склейкой перед использованием, а то и вовсе без оной.
Различных способов реализовать наследование или его подобие при отсутствии встроенной в язык поддержке ООП очень много. Покажите где хотя бы один из них используется в статье. У вас написано «from a import *». У автора такого нет. Наличие возможности использования ООП тем или иным способам не делает любой код использующим ООП. Я, к примеру, могу написать пачку классов вида
from math import acos, atan, sin, cos
class CoordCartezian:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def distance(self, c2):
return ((self.x-c2.x)**2 + (self.y-c2.y)**2 + (self.z-c2.z)**2) ** 0.5
def spherical(self):
r = (self.x*self.x + self.y*self.y + self.z*self.z) ** 0.5
return CoordSpherical(
r,
acos(self.z/r),
atan(self.y/self.x)
)
class CoordSpherical:
def __init__(self, r, t, p):
self.r = r
self.t = t
self.p = p
def angle(self, c2):
return acos(sin(self.t)*sin(self.p)*sin(c2.t)*sin(c2.p) + sin(self.t)*cos(self.p)*sin(c2.t)*cos(c2.p) + cos(self.t)*cos(c2.t))
def cartezian(self):
return CoordCartezian(
self.r * sin(self.t) * cos(self.p),
self.r * sin(self.t) * sin(self.p),
self.r * cos(self.t)
)
и так далее, но пока эти классы не начнут наследоваться друг от друга или хотя бы реализовывать одинаковые интерфейсы весь этот код будет процедурным, в котором просто для удобства к структурам были присобачены методы. В библиотеке с такими классами ООП нет. А классы есть.
Так что вопрос не в том, можно ли реализовать принципы ООП на модулях. Как уже сказано, ООП можно реализовать даже на ассемблере. Вопрос в том, где вы нашли ООП в статье?
Купил недавно Motorola Droid 4 (на ebay), у телефона обнаружилась, как потом оказалось, известная проблема: при использовании зарядки сенсоры экрана не работают как положено. Как думаете, на каких зарядках они‐таки работают? На фирменной от Motorola (требует переходника, вместо которого на постоянно‐временной основе выступает примотанный изолентой обрезок шнура питания от компьютера), фирменной от iPad (2,1 ампера, я таким током постоянно заряжать не рискну) и фирменной от Fly (ток, наоборот, маленький, сейчас точно не вспомню, какой, но, кажется, 0,6 ампера). Зарядка от Zopo, а также все прочие не работают. Ещё работает зарядка от компьютера, но там ток ещё меньше, чем у зарядки от Fly.
Нет. Qubes нужен, чтобы защитить от вещей вроде переполнения буфера в программах, просматривающих файлы. Поищите для примера «Acrobat Reader 0day»: даже на habrahabr два топика. Оснований полагать, что подобных вещей в остальных программах нет, у меня нет. Я также не считаю, что песочница в Android может изолировать на том же уровне, что и полноценная виртуалка в Qubes. А Qubes нужны определённые возможности процессора, связанные с виртуализацией, так что любой китайский планшет не подойдёт.
В идеале в таком устройстве вообще должно быть две платы, получающие данные от компьютера одновременно: одна занимается только подписыванием и единственная имеет доступ к USB на запись (т.е. на отправку) и к клавиатуре. Другая — только отображением, причём система полностью перезагружается после отображения каждого документа.
Именно при оплате можно отображать на экране устройства сумму и получателя перед подписью, тогда будет видно, что именно вы подписываете и троян ничего не сделает — если вы, конечно, не забываете всё проверить. Только для отображения подписываемых документов требуется экран побольше и ПО потенциально (и, наверняка, реально) поуязвимее. Или ПК с чем‐то вроде Qubes (дистрибутив linux от экспертов по информационной безопасности, широко использует виртуальные машины для обеспечения оной).
Замечу, что во всех ридерах всех магазинов, которые я видел, сумма действительно отображается. Получатель — нет, но в магазинах он и не нужен.
Это хорошо. Одна из вещей, которые мне нравились в Opera — это возможность поместить настройки под контроль mercurial. В некоторых местах, конечно, была куча вещей, которые настройками не являются (вроде времени последнего запуска проверки обновлений и версии), но терпимая куча; с бинарными файлами у остальных даже такой каши не сваришь.
Если на решения на этом сайте меня приводит гугл (и решения работают), однако, очевидно, если соответствующих вопросов там нет, то и гугл меня туда не приведет. В таком случае, что мне стоит ответить?
Я этот вопрос прочитал как «Вы всегда достигаете успеха в решении проблем с помощью StackOverflow.com, когда пишете там свой вопрос?» Если это именно то, что имел ввиду автор, то отвечать вам не надо вообще. Если же нет, а вы попадаете на сайт только через Google, не пользуясь его встроенным поиском, то логично было бы прикинуть соотношение решений, которые можно было бы ожидать на SO, к реально найденным там решениям. Или, опять же, нажать «воздержаться».
Если интересно, то мой ответ был соответственно: «больше нет, чем да»: с относительно простыми вопросами я обращаюсь в документацию, поисковик, IRC или исходники проекта, где ответ на этот вопрос предположительно найден (в порядке предпочтения; первые два варианта помогают в большинстве случаев). А то, на что не могу ответить я после чтения документации, что не может найти поисковик и что слишком сложно для выяснения через IRC — на такие вопросы и на SO не отвечают. Учитывая то, что я предпочитаю не обращаться на SO с тривиальными проблемами, ответы «больше нет, чем да» и «почти никогда» с моей поправкой к вопросу весьма логичны.
Кстати, в случае с mercurial с или без changeset evolution тот, кто делал rebase, мог бы восстановить контекст и объяснить действия Василия (с changeset evolution это мог бы дополнительно сделать любой, кто сделал pull до rebase; правда требуется либо настройка сервера, чтобы он не считал находящиеся на нём изменения публичными, либо принудительное выставление фаз администратором на сервере и rebase его же силами). Без changeset evolution rebase делает резервные копии удаляемых изменений в .hg/strip-backup, с — просто оставляет их в репозитории (никакого автоматического gc!). Git же оставляет эти резервные копии на милость своего gc.
Такого рода изменения, кстати, хорошо показывают, у кого лучше архитектура. Я лично не знаю ни одного примера добавления возможности в, так сказать, ядро git с самого момента начала его мною использования. В Mercurial же спокойно добавляют largefiles, phases и changeset evolution, да ещё и без проблем с совместимостью.
Не говоря уже о том, что рабочий прототип на Python с использованием довольно неплохого внутреннего API (позволяющего в т.ч. изменять поведение встроенных команд), написать гораздо легче, чем тот же прототип для git на C без специальной поддерки изменения поведения команд со стороны уже имеющегося кода.
Сейчас в mercurial пилят changeset obsolescense: хотя эта возможность и предполагается как замена MQ, я в первую очередь вижу в ней возможность полностью безопасного изменения истории (в репозитории остаются все изменения, просто при переписывании mercurial указывает, что данное изменение является obsolete, указывает, что данное изменение является заменой другого (или наоборот, указывает, какое изменение является заменой данного — не узнавал, в метаданных какого изменения всё это сохраняется), а также по‐умолчанию отдаёт только не‐obsolete изменения (дополнительно скрывая уже имеющиеся)).
Есть и дополнение, автоматическим образом разрешающее часть проблем вроде «изменение в вашем репозитории имеет obsolete предка» и д.р. Поищите «mercurial changeset obsolescense». То есть, теперь уже «mercurial changeset evolution».
У mercurial это стандартное дополнение (т.е. присутствует сразу после установки, но отключено). Если напишете hg rebase, не включив его, то получите
hg: неизвестная команда 'rebase'
'rebase' предоставляется следующим расширением:
rebase команда для перемещения наборов ревизий к другому предку
наберите "hg help extensions" для справки по включению расширений
И это есть. Другое дело, что в mercurial такое действие предлагается проделать двумя командами: есть просто rebase и histedit, который может перетасовать/убрать изменения как rebase -i, но не перенести их в другую ветку.
Можно и так. Только transplant — хорошее, запоминающееся имя (т.к. заимствованные слова на его базе всё время на слуху), а graft я как несколько раз видел, так и не запомнил. Судя по словарю является медицинским и садоводческим термином. И с двумя разговорными вариантами, не имеющими к цели команды отношения, — взятка/взяточничество и (брит.) работа. Кальк и заимствований на основе graft я ни разу не слышал, само слово без контекста «есть такая команда в Mercurial» — тоже.
Только на ситуацию мы смотрим с несколько разных сторон. Вы, похоже, работаете в компании, а я в основном работаю с СПО в свободное время. Поэтому CI сервера либо нет, либо это travis, который при всех своих достоинствах будет собирать намного медленнее, чем это возможно на моей машине. Поэтому получать необходимые для сборки файлы из ещё одного репозитория мне не очень удобно. Поэтому я так рекламирую largefiles, несмотря на то, что сами разработчики обозвали её «feature of last resort».
Там вы расписали что‐то не так.
Вот этот комментарий, на который я отвечаю, действительно описывает проблему. Но фикс, о котором вы говорите, надо проверить. Для этого ПО надо собрать. Для этого бинарники нужны. Если они не нужны для сборки, то их надо засунуть в другой репозиторий. Вы же не будете возражать, если рядом с этим репозиторием будет лежать другой, к примеру «static_content», с кучей бинарников? Или что фиксы надо проверять?
Это уже всё организационный вопрос. Хранить ненужные бинарники вместе с исходным кодом не нужно. Я, правда, не занимался разработкой для web и потому не могу сказать, насколько эти несколько гигабайт «хлама» могут быть нужны для тестов. Возможно, что вы огорчаетесь зря. Но если я вижу, что человек засунул скомпилированные бинарники, пачку установщиков для всех поддерживаемых систем и все снимки экрана, которые он использует на своём сайте, к исходному коду, то я тоже огорчаюсь. (Правда, таких разработчиков я ещё, к счастью, не видел.)
Другое дело если бинарники не являются необходимыми для сборки. Но это вопрос организации разделения на репозитории, не вопрос того, подходят ли системы контроля версий для хранения бинарников.
// Кстати, с бинарниками и сжатием есть как всегда возможность получить overhead вместо сжатого файла. Так что я даже и не думал говорить о том, что наличие сжатия может сделать конкретную СКВ пригодной для хранения бинарных данных.
splitи собирать обратно на CI сервере нежели использовать хэш и хранить исходные файлы (если, конечно, они тоже превышают данный размер) где‐то ещё.То есть запретить такие файлы можно. Но максимум, чего вы добьётесь — «заставите задуматься». Во всех случаях хранения таких файлов в git, которые я могу себе представить, может быть использована резка их
splitом с последующей склейкой перед использованием, а то и вовсе без оной.from a import *». У автора такого нет. Наличие возможности использования ООП тем или иным способам не делает любой код использующим ООП. Я, к примеру, могу написать пачку классов видаи так далее, но пока эти классы не начнут наследоваться друг от друга или хотя бы реализовывать одинаковые интерфейсы весь этот код будет процедурным, в котором просто для удобства к структурам были присобачены методы. В библиотеке с такими классами ООП нет. А классы есть.
Так что вопрос не в том, можно ли реализовать принципы ООП на модулях. Как уже сказано, ООП можно реализовать даже на ассемблере. Вопрос в том, где вы нашли ООП в статье?
Купил недавно Motorola Droid 4 (на ebay), у телефона обнаружилась, как потом оказалось, известная проблема: при использовании зарядки сенсоры экрана не работают как положено. Как думаете, на каких зарядках они‐таки работают? На фирменной от Motorola (требует переходника, вместо которого на постоянно‐временной основе выступает примотанный изолентой обрезок шнура питания от компьютера), фирменной от iPad (2,1 ампера, я таким током постоянно заряжать не рискну) и фирменной от Fly (ток, наоборот, маленький, сейчас точно не вспомню, какой, но, кажется, 0,6 ампера). Зарядка от Zopo, а также все прочие не работают. Ещё работает зарядка от компьютера, но там ток ещё меньше, чем у зарядки от Fly.
В идеале в таком устройстве вообще должно быть две платы, получающие данные от компьютера одновременно: одна занимается только подписыванием и единственная имеет доступ к USB на запись (т.е. на отправку) и к клавиатуре. Другая — только отображением, причём система полностью перезагружается после отображения каждого документа.
Замечу, что во всех ридерах всех магазинов, которые я видел, сумма действительно отображается. Получатель — нет, но в магазинах он и не нужен.
Кстати, а нельзя ли засунуть RSS обратно в браузер как nsplugin типа acroread для чтения PDF?
Если интересно, то мой ответ был соответственно: «больше нет, чем да»: с относительно простыми вопросами я обращаюсь в документацию, поисковик, IRC или исходники проекта, где ответ на этот вопрос предположительно найден (в порядке предпочтения; первые два варианта помогают в большинстве случаев). А то, на что не могу ответить я после чтения документации, что не может найти поисковик и что слишком сложно для выяснения через IRC — на такие вопросы и на SO не отвечают. Учитывая то, что я предпочитаю не обращаться на SO с тривиальными проблемами, ответы «больше нет, чем да» и «почти никогда» с моей поправкой к вопросу весьма логичны.
.hg/strip-backup, с — просто оставляет их в репозитории (никакого автоматического gc!). Git же оставляет эти резервные копии на милость своего gc.Не говоря уже о том, что рабочий прототип на Python с использованием довольно неплохого внутреннего API (позволяющего в т.ч. изменять поведение встроенных команд), написать гораздо легче, чем тот же прототип для git на C без специальной поддерки изменения поведения команд со стороны уже имеющегося кода.
Есть и дополнение, автоматическим образом разрешающее часть проблем вроде «изменение в вашем репозитории имеет obsolete предка» и д.р. Поищите «mercurial changeset obsolescense». То есть, теперь уже «mercurial changeset evolution».
hg rebase, не включив его, то получите.