Я не смог сдержаться и честно скопипастил оттуда статью про Git

В trunk появилась новая долгожданная фича: Scalar type hints

Выглядит это приблизительно так:

< ?php
function doSomething( int $foo){
echo "{$foo}\n";
}
?>

Если в такую функцию передать не целое – получим Catchable fatal error

Меркуриал в последнее время стал моей основной системой контроля версий, и естественно у меня появился некоторый опыт, которым по моему мнению пора бы и поделиться.

Начнем с небольшого сравнения со старым добрым Subversion.

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

Чуть позже при написании статьи вспомнил еще один, уже достаточно серьёзный недостаток — невозможность забрать часть репозитория. В любой современной децентрализованной системе контроля версий репозиторий является единой сущностью, а потому стянуть на машину разработчика только часть репозитория, как в Subversion и CVS не выйдет. Однако проблема с разделением репозитория решается именно его РАЗДЕЛЕНИЕМ.

Теперь попытаюсь вспомнить преимущества.

Локальный игнор-файл — файл содержащий паттерны для исключения файлов/каталогов из-под контроля версий может контроллироваться системой, а может быть так же исключен из-под контроля. Последний вариант дает разработчикам огромные возможности для хранения внутри рабочей копии дополнительных файлов, таких, как например инструменты разработчика, sql-дампы, да все, что только можно придумать. Простейший пример: Одни разработчики используют Eclipse, другие Netbeans, третьи Komodo, а каждая из этих сред создает в корне проекта файлы с мета-информацией о проекте. Включать эти файлы и папки в контроль версий смысла нет, а добавлять все возможные варианты в игнор, грозит его разрастанием.

Автоматический бэкап. Это преимущество неоспоримо, ведь каждый из разработчиков имеет на своей машине самодостаточный репозиторий, который можно в любой момент сделать главным (ну если вдруг сервер упал… с пятого этажа).

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

Для начала немного теории! Помните централизованные системы контроля версий? Там есть единый репозиторий в который мы коммитим и с которого обновляем нашу рабочую копию. В распределенных системах репозиторий находится прямо внутри рабочей копии. В Меркуриал репозиторий хранится в каталоге .hg прямо в корне проекта (рабочей копии). Все фиксации изменений и обновления происходят локально. Казалось бы все как и в централизованной системе, однако при надо же как-то делиться изменениями с другими разработчиками? Вот тут и начинается та самая распределенность. Чтобы опубликовать (протолкнуть в терминологии Mercurial) наши изменения в общий репозиторий (вспоминаем? система распределенная – репозиториев много) мы должны их сначала зафиксировать локально (commit), и только потом отправить в обший репозиторий (push). Для того, чтобы получить чужие изменения в свой локальный репозиторий (втягивать в терминологии Mercurial) мы должны выполнить комманду pull (тянуть). Когда чужие изменения уже находятся в нашем репозитории мы можем иметь 2 ветки изменений – 1) ветка наших изменений с несколькими коммитами 2) ветка чужих изменений тоже с несколькими коммитами. Ветки в итоге сходятся к одному родительскому узлу (changeset или «набор изменений» в терминолонии Меркуриал)

…… продолжение следует…

Запуск netbeans, установленного из пакетов в sun-java-runtime не лечится стандартными средствми типа update-alternatives.

Только правкой /usr/share/netbeans.platform11/lib/nbexec
Добавляем в 512 строку export jdkhome=/usr/lib/jvm/java-6-sun

В математике функция отображает объекты из одного множества (множества определения функции) в другое (множество значений функции). Математические функции (их называют чистыми) “механически”, однозначно вычисляют результат по заданным аргументам. Чистые функции не должны хранить в себе какие-либо данные между двумя вызовами. Их можно представлять себе черными ящиками, о которых известно только то, что они делают, но совсем не важно, как.

Read the rest of this entry »