Pull to refresh
58
0
Денис Обыденных @DenisO

Пользователь

Send message
Куча слов в защиту опен сорса. Как будто ОМОН туда пошел из-за опен сорса.
Нет, защищать надо частную собственность. Туда пришли ради денег, которые компания недавно получила. И всем это понятно.

Защищать надо частную собственность. Но к сожалению момент упущен, и вы, Григорий, делать этого не можете — ни лично, ни в формате компании. Ведь в случае чего — в Яндекс тоже придут люди в бронежилетах и с автоматами.

Только сказать об этом вы не можете, так как свободу слова раньше тоже никто защитить не смог. И всем все понятно, но сказать об этом уже тоже нельзя.
➜ cd Downloads && grep amigo go-pulse.exe
> Binary file go-pulse.exe matches

Греп не врет ;)
Одураченные случайностью — это одна из первых книг Нассима Талеба. Логичнее читать более поздние — доработанные книги. К примеру, Черный Лебедь. Там он дополняет и более проработанно излагает мысли.
как и material design
Может имеет смысл вставить ссылку на коммент внутри статьи? :)
Спасибо за перевод. В целом статья очень полезна. )

Только вот этот момент смутил:

Когда нам нужно сделать слияние, Subversion смотрит на обе ревизии — мой измененный код и ваш измененный код — и пытается угадать, как слепить их вместе в один большой страшный бардак. Обычно Subversion это не удается, и получаются длинные списки конфликтов («merge conflicts»), которые на самом деле не конфликты, а просто места, в которых система не смогла разобраться в наших изменениях.

Для сравнения, если мы независимо работали в Mercurial, то система сохраняла серии изменений. Таким образом, когда мы хотим сделать слияние кода, у Mercurial на самом деле гораздо больше информации: система знает, что каждый из нас изменил, и может заново применить эти изменения вместо того, чтобы смотреть на конечный вариант и пытаться угадать, как все это собрать воедино.

Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше.

Так как Mercurial мыслит в терминах наборов изменений, вы можете делать интересные вещи с этими наборами изменений. Вы можете дать попробовать эти изменения другу вместо того, чтобы вносить эти изменения в центральный репозиторий и вынуждать всех ими пользоваться.

Если все это кажется вам немного запутанным — не переживайте. По мере чтения этого пособия все обретет ясный смысл. В данный момент самое главное, что вам нужно знать: из-за того, что Mercurial оперирует наборами изменений, а не ревизиями, слияние кода в Mercurial работает гораздо лучше, чем в Subversion.


Вот тут — либо неточность, либо недостаточно раскрыта тема в статье.

Какая разница — changeset или слепок файлов система хранит? Откуда у меркуриала больше информации?

В любом случае если я
в ветке А — удаляю функцию из одного файла, вставляю в другой.
в ветке Б — меняю тело функции на пару строк

Ниодна система контроля версий этого сама не смерджит. Мне кажется ближе к истине вот это programmers.stackexchange.com/a/129926

Subversion, Mercurial, and Git all track repository-wide snapshots of the project. Calling them versions, revisions, or changesets makes no difference. They are all logically atomic snapshots of a set of files.

The size of your commits makes no difference when it comes to merging. All three systems merge with the standard three-way merge algorithm and the inputs to that algorithm are

greatest common ancestor version
version on one branch
version on other branch
It doesn't matter how the two branch versions were created. You can have used 1000 small commits since the ancestor version, or you can have used 1 commit. All that matters is the final version of the files. (Yes, this is surprising! Yes, lots of DVCS guides get this horribly wrong.)



The real reason Git and Mercurial are better at merging than Subversion is a matter of implementation. There are rename conflicts that Subversion simply cannot handle even thought it's clear what the correct answer is. Mercurial and Git handles those easily. But there's no reason why Subversion couldn't handle those as well — being centralized is certainly not the reason.
Вот этот момент смутил в статье.

Когда нам нужно сделать слияние, Subversion смотрит на обе ревизии — мой измененный код и ваш измененный код — и пытается угадать, как слепить их вместе в один большой страшный бардак. Обычно Subversion это не удается, и получаются длинные списки конфликтов («merge conflicts»), которые на самом деле не конфликты, а просто места, в которых система не смогла разобраться в наших изменениях.

Для сравнения, если мы независимо работали в Mercurial, то система сохраняла серии изменений. Таким образом, когда мы хотим сделать слияние кода, у Mercurial на самом деле гораздо больше информации: система знает, что каждый из нас изменил, и может заново применить эти изменения вместо того, чтобы смотреть на конечный вариант и пытаться угадать, как все это собрать воедино.

Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше.

Так как Mercurial мыслит в терминах наборов изменений, вы можете делать интересные вещи с этими наборами изменений. Вы можете дать попробовать эти изменения другу вместо того, чтобы вносить эти изменения в центральный репозиторий и вынуждать всех ими пользоваться.

Если все это кажется вам немного запутанным — не переживайте. По мере чтения этого пособия все обретет ясный смысл. В данный момент самое главное, что вам нужно знать: из-за того, что Mercurial оперирует наборами изменений, а не ревизиями, слияние кода в Mercurial работает гораздо лучше, чем в Subversion.


Какая разница — changeset или слепок файлов система хранит? В любом случае если я удаляю функцию из одного файла, вставляю в другой.
Думаю если он тут выступает примером — можно было бы и ссылку поставить. Типа смотрите как бывает. И он был бы благодарен. )

Насчет многих — так и есть. В целом по жизни. Я по провинц-ТВ видел сюжет, как награждали за 25 лет службы. В ато/троллейбусном депо, или еще каком таком месте. За одну и туже работу. Наградили.

Так что в определенной мере это даже поощряется.
Видимо блог Спрута? Он на своей волне. Вместо работы — занимается путешествиями.
Стоит переименовать новость в "Субсидированые возобновляемые источники в США сравнялись с классическими по стоимости полученной электроэнергии"

Тк это слово сильно влияет на смысл новости.
Совмещение научно-теоретической деятельности с практической.

Кстати, это в Питерском офисе?
Очень радует что вы проводите подобные эксперименты.
Вы нашли как его найти? Сам в поисках
Это описание — достойно экранизации!
Альтернативный ответ. В случае проблем — начинаю проверять. Недавно поиск с гугла стал проходить через левый домен. Оказалось "[какой-то] Resizer" — расширение для изменения размеров окна браузера стало так монетизироваться.
Но здесь вовремя подоспел г-н М.Цукерберг, описавший мытарства Facebook в этой области. Наверное это стало решающим аргументом в пользу нативного iOS приложения

А можно ссылку или наводку где почитать про эти мытарства?
The exploit we analyzed worked only on Windows XP or Windows 7 running Internet Explorer 8 or 9.
Детали реализации всего были бы очень к месту
Я еду в воскресенье 16 июня из Москвы в СПб. Готов помочь с доставкой сервера, если найдутся достойные. )
Отличные инструменты. Еще бы поддержку sass. )

Information

Rating
Does not participate
Registered
Activity