Встречаем Veracity — новую распределенную систему контроля версий

Я не говорил, что Mercurial — синоним этого понятия. Я сказал, что veracity напоминает Mercurial в большей степени, чем Git (поэтому мне было непонятно, почему в статье написано «схожая с Git»). Ни одно из перечисленных мною сходств не является необходимым для того, чтобы система называлась «DVCS».

Встречаем Veracity — новую распределенную систему контроля версий

Поправка: Mercurial будет смотреть на сходство, если использовать hg addremove --similarity.

Встречаем Veracity — новую распределенную систему контроля версий

# На исходниках git:
$ git mv ws.c wss.c
$ echo 1>wss.c
$ git add wss.c
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    ws.c
#       new file:   wss.c
#
$ git reset --hard HEAD
$ git mv ws.c wss.c
$ git commit -m 'ABC'
$ git diff --name-status HEAD^..HEAD
D       ws.c
A       wss.c
$ git diff --name-status -C HEAD^..HEAD
R100    ws.c    wss.c

# На исходниках mercurial:
$ hg mv README README.md
$ echo 1>README.md
$ hg status -C
A README.md
  README
R README

Git не сохраняет информацию о переименованиях, он смотрит на процент сходства. То же, что я говорил, просто это поведение по‐умолчанию у некоторых команд. Mercurial, наоборот, никогда не смотрит на сходство файлов.

Встречаем Veracity — новую распределенную систему контроля версий

Всё верно. Посмотрите git help diff, там есть ключи --find-renames, --find-copies, --find-copies-harder. Если бы git сохранял информацию о переименованиях, зачем бы были нужны такие ключи?

Встречаем Veracity — новую распределенную систему контроля версий

Формальное переименование файлов, возможность написания хуков на языке программирования, локальные номера ревизий, неизменность истории (если я правильно понял, что на сайте имеется ввиду под «immutability doctrine»), ветки, являющиеся свойством ревизии (а не просто указателями на конкретную ревизию как в git), команды вроде incoming/outgoing, heads, serve. Это всё подозрительно напоминает отнюдь не Git, а Mercurial.

Некоторые особенности VimL

У Vim есть множество интерфейсов с другими языками. И Bram нормально принимает доработки к ним, если вы их напишете.

Это не значит, что всё идеально: не хватает двух вещей:

1. Этих самых доработок
2. Официального C API

Без первого писать всё так же будет нелегко, в нынешней стадии интерфейсы отнюдь не идеальны. Поддержка Python, насколько я знаю, сделана на сейчас лучше всего (после моего патча, добавляющего pyeval()/py3eval() и vim.bindeval(), до того лучше было у lua), но моей единственной целью на момент написания было избавление от весьма прожорливой сериализации/десериализации, являвшейся единственным способом вернуть данные обратно в VimL.

Без второго будет сложно делать первое. При написании патча, к примеру, несколько static функций из eval.c перестали быть таковыми. В интерфейсе с lua они, кстати, почему‐то были просто скопированы из eval.c и уже устарели.

Идеальной реализацией второго, по моему мнению, может быть такая, при которой VimL станет таким же дополнением, как и Python. Но это работа, сопоставимая по сложности с написанием Vim с нуля.