Открыть список
Как стать автором
Обновить

Комментарии 70

Не такая уж она и новая. У меня уже больше полугода на полке стоит их «Version Control by Example», очень неплохая и интересная книга. Когда-то они их бесплатно высылали, когда только дебютировали. Но пока так и не нашел особых преимуществ перед git. Из недостатков — пока что слабая интеграция с IDE.
Согласен, что не совсем новая. Все не было времени написать про нее.
Ну, начинание ок, но при наличии гита…
А мне как-то все это сильно напоминает меркуриал. Но в целом принципиально нового не услышал.

Вообще, хотелось бы почитать сравнение именно с этой VCS.
На главной странице проекта есть сравнительная таблица veracity-scm.com/
вы пользуетесь этой системой контроля версий?
как у нее со скоростью по сравнению с git? лучше/хуже merge?
и для чего поддержка нескольких хэш функций?
Если честно, то сам пользуюсь Git. Для моих нужд она сыровата и лично мне не хватает staging. Однако мне нравятся некоторые идеи, заложенные в ней и я просто слежу за ее развитием. По поводу хэш-функций, например, SHA-2 отличается от SHA-1 тем, что для нее пока что не обнаружено коллизий, то бишь возможно их значительно меньше.
а в Git разве стоит эта проблема? коллизия в репозитории — это что-то очень маловероятное, на мой взгляд.
Нет, не стоит. По поводу коллизий это было лишь предположение.
Тут ещё дело в том, что хэш часто используется для подтверждения аутентичности коммита: если ченджсет существовал в репозитории вчера с таким хэшем, то почти наверняка завтра можно будет сказать, что это тот же самый ченджсет.

Но, если вспомнить проблему со взломом серверов kernel.org — команда разработчиков проверяла достоверность по каким-то своим цифровым подписям, не доверяя хэшу.

(хотя я не совсем детально в это всё вникал, возможно я и наговорил какую-то фигню :-)
Наверно имеется ввиду git commit -s.
Нифига не понял. Очевидно, что в хеш-функции M бит в N число коллизий равно exp(M-N).
с каких пор отсутствие механизма блокировки файлов стало недостатком? Всю жизнь думал что слияние — это плюс, устраняющий недостаток, в лице блокировки.
Это не недостаток, но для бинарных файлов блокировка удобнее. Лично мне часто приходится редактировать схемы баз данных для разрабратываемого приложения. Эти схемы хранятся в бинарном виде. Хорошо, что используемая в проекте Subversion это поддерживает.
Поясните немного про блокировку. Я правильно понял, что если вы заблокируете файл, никто другой не сможет запушить изменения в этот файл, пока вы его не разблокируете?
Как тогда будет выглядеть ситуация: сфетчил репозиторий, локально сделал с десяток коммитов, пушишь — а там файл заблокирован? В git вместо блокировки был бы конфликт, а тут как?
Я не очень понимаю, как децентрализованность вяжется с блокировками.
Ведь блокировка будет работать только если есть связь со всеми остальными репозиториями — иначе как там заблокировать файл. А значит система получается очень махрово централизованная — причем связь должна быть не просто с центральным сервером, а каждого репозитория с каждым. Имхо это еще хуже.
Или я что-то упустил?
В документации написано, что для создания блокировки необходим доступ в сеть, то бишь действительно будет осуществляться соединение с удаленным сервером и передача ему информации о блокировке. Если вы используете блокировки, то теряете децентрализованность, тут уж никуда не деться.
Значит, это не децентрализованная система, а очень централизованная, где все должны сидеть в одной комнате, чтобы нормально работать друг с другом.
Представьте, один разработчик из команды работает на своем ноутбууке и полетел на конференцию. Пока он летит, вы работать не можете — т.к. он все сети и непонятно как сделать блокировку. Либо на это время вы должны исключить его из списка блокирования. Но тогда получается, что у вас по сути нет блокировок! Ведь если он внесет какие-то изменения в систему, то он это сделает без учета блокировок, что может привести к конфликтам. А система, похоже, построена на идее, что блокировка спасет.

Вообще, для понимания какие проблемы могут возникать в таких вещах (и многих других) есть замечательная CAP-теорема Брюера:
В распределённой системе невозможно обеспечить одновременное выполнение всех трёх условий: корректности (С), доступности (А), устойчивости к сбоям узлов (Р).

Как говорится: выберите 2 из 3. Оставшимся придется пожертвовать.

Несколько человек, работающих над одним проектом, это уже распределенная система, даже если они никакую VCS не используют, а тупо заливают файлы по FTP. Это так уже потому, что у каждого из них «чуть свой» вариант проекта. Никакая VCS не сможет обеспечить решение всех трех проблем сразу, поэтому не нужно пытаться изобрести суперсистему, которая всех сделает счастливыми. Лучше сразу изобрести вечный двигатель. Задача VCS — облегчить рутинные проблемы разработчиков.
Каждая из них это делает по-своему:
CVS может это решить с помощью блокировок. То есть корректность и устойчивость к сбоям узлов обеспечивается ценой доступности для разработчиков. Если возникает конфликт одновременного изменения, то кто-то должен ждать — то есть для него персонально система не доступна.
GIT жертвует корректностью, зато система всегда доступна и устойчива к выпадению и появлению узлов. Но при этом конфликтные изменения дадут вам проблему при объединении веток. Автоматически это не решается — требуется вручную просмотреть изменения и решить какие и как принять.
Veracity (как написано) выбирает корректность и доступность, значит она не устойчива к сбоям узлов. Зато в системе вы сможете бесконфликтно и надежно работать. Ровно до тех пор, пока не выпадет из работы один из узлов. После чего имеющиеся на нем конфликтные изменения нужно будет руками сливать. Просто вернуться в строй он не сможет.

Из всех рассмотренных вариантов наиболее адекватным мне кажется подход GIT, т.к. обеспечивает максимальную работоспособность в распределенном окружении. При этом жертвует самым неважным — способностью автоматически обеспечивать корректность репозитория. В данном случае это логично: т.к. программист все равно так или иначе ревизирует код, поэтому полезно еще раз просмотреть потенциально опасные изменения.
> Git при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.

Точно? Насколько помнится, такая проблема существовала в меркуриале, но не в гите.
Всё верно. Посмотрите git help diff, там есть ключи --find-renames, --find-copies, --find-copies-harder. Если бы git сохранял информацию о переименованиях, зачем бы были нужны такие ключи?
Из того, что в команде diff есть такие ключи, не значит, что git не умеет нормально переименовывать файлы. Верно?
Провёл эксперимент
$ du -sh .git/
484K .git/

$ git mv binary binary2

$ git status
# On branch master
# Changes to be committed:
# (use «git reset HEAD ...» to unstage)
#
# renamed: binary -> binary2
#

$ git commit -am «rename»
[master 1b8d156] rename
1 file changed, 0 insertions(+), 0 deletions(-)
rename binary => binary2 (100%)

$ du -sh .git
500K .git

ps: отдельное спасибо минусовавшим, которые не разобравшись жмут на кнопку. Удачного вам дня.
# На исходниках 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, наоборот, никогда не смотрит на сходство файлов.
Я с этим и не спорю :-)

Изначальная фраза, которую я комментировал:

> Git при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.

Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.

Подытоживая: я не говорил, что гит сохраняет информацию о переименованиях, но я говорил, что никакого «удалить и потом создать такой же» там не происходит, а всё несколько более интеллектуально.
Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.

Нет. Git отслеживает изменения _содержимого_ файлов, а не сами файлы. Вы можете скопировать файл 10 раз, и это не приведет к увеличению репозитория, в котором однажды этот файл был проиндексирован. Будут лишь созданы ссылки на ранее сохраненный объект, идентифицируемый хешем от содержимого файла. С удалением файла и последующим добавлением — та же самая ситуация (поскольку из истории объект не удалялся, при повторном добавлении его в репозиторий будет лишь создана ссылка на старый объект).
Поправка: Mercurial будет смотреть на сходство, если использовать hg addremove --similarity.
попробуйте git gc размер должен уменьшиться
Эм, куда ему ещё уменьшаться? Я же показал своим примером, что содержимое файла дважды не пишется. М?
Я понимаю это. Но откуда в данном случае им вообще возникнуть?

ps: я бы даже сказал, что будут почищены недоступные объекты, которые могут возникнуть в случае git reset, удаления несмердженного бренча, итд

Поясните, что именно вы хотели сказать, потому как на данном этапе это не совсем ясно.
PPS:

вы уверены, что вы внимательно посмотрели вывод всех моих команд? Посмотрите, пожалуйста, внимательно ещё раз — между комитами разница минимальная, на размер метаинформации. Так что куда ещё вы хотите уменьшить репозиторий — не совсем ясно.
Ну как раз в меркуриале такой проблемы нет, он полностью поддерживает и переименования, и их автоматическое обнаружение (т.е. когда переименовал не через hg mv, просто через mv, а потом уже опомнился).
Он поддерживает переименование и автообнаружение, но само хранилище НЕ УМЕЕТ до сих пор (хотя в трекере периодически создаются соответствующие баги) в самом индексе переименовывать файл. Как результат получаем удвоение размера.

Вот вам пример:

$ du -sh .hg
2.6M .hg

$ hg mv binary binary2

$ hg st
A binary2
R binary

$ hg commit -m «rename»

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

Просто, многое из того что вы описали как фишку, в меркуриале было представлено уже давно. А хотелось бы прочитать именно об уникальных особенностях данной системы.
Полностью согласен. Тоже по ходу статьи не покидало ощущение, что это mercurial + возможность блокировки файлов.
Ага. Например «Veracity хранит большинство служебной информации о репозитории вне рабочего каталога в специальной базе данных. Это, например, позволяет иметь сразу несколько рабочих каталогов для одного репозитория.» — не помню как в git, но в mercurial локальный clone в позикс-системах — это тоже дешевая операция, так как большинство информации репозитория шарится с помощью хардлинков файловой системы.
git тоже по-умолчанию создает жесткие ссылки вместо копирования для локальных каталогов
mercurial не является модным синонимом понятия DVCS
Я не говорил, что Mercurial — синоним этого понятия. Я сказал, что veracity напоминает Mercurial в большей степени, чем Git (поэтому мне было непонятно, почему в статье написано «схожая с Git»). Ни одно из перечисленных мною сходств не является необходимым для того, чтобы система называлась «DVCS».
непонятно, почему в статье написано «схожая с Git»
потому, что git как раз и является модным в этом сезоне синонимом слова dvcs. а с mercurial автор, по всей видимости, незнаком. Я бы даже сказал «активно незнаком», т.к. проигнорировал табличку с veracity-scm.com/
В чем цель создания этого проекта? Какую проблему он решает? Какие задачи ставят себе разработчики?
У Линуса была совершенно четкая цель — быстро сделать нормальную удобную децентрализованную систему для разработки ядра Линукс. Все понимали что и для чего делается — в итоге создали хорошую cистему.
Здесь я пока что вижу «давайте сделаем как в git, только по-другому».
Честно говоря я не знаю в чем была цель разработчиков Veracity, но точно знаю, что моя цель была рассказать об этом чуде.
Вы-то своей цели достигли :)
оно решает проблему заменяемых бэкендов для метаданных. как результат, VCS становится более совместима с различными policy отдела ИБ и/или «сертифицированными решениями» за $100500. Как результат,
1. у sourcegear появляется много вкусных клиентов (профит)
2. кровавый enterprise переходит на DVCS (добро)
in before «проблемы не существует» — ну сложите содержимое .git в БД например.
Децентрализованная база данных репозитория
Получается, наоборот — в Veracity централизованная на все проекты, а в git — на каждый в отдельности.
К слову, в git можно настроить расположение .git папки на своё усмотрение, не обязательно хранить её внутри проекта.
Оффтоп: у меня одного таблица команд кривая? Первый столбец ровно 2 символа шириной.
Такое ощущение, что они изобрели mercurial. Из перечисленного он может все, кроме раздельного хранения служебной информации. Но это достаточно спорная фича — да, можно делать несколько директоий с низким оверхедом, зато эти директории нельзя перемещать средствами файловой системы.
На самом деле я еще и не совсем уверен нужно ли было использовать вообще SQLite для создания подобных систем. Git вот абсолютно спокойно обходится простыми текстовыми файлами.
На самом деле, это классно.
В меркуриале это тоже есть, только в немного другом виде. Здесь сделано больше как в Fossil (да и SQLite как back-end тоже используют).
один исполняемый файл и он же выступает вебсервером — таки да, Fossil.
это mercurial на стероидах с заменяемыми storage backends. во всяком случае, таков был изначальный план.
Должен признаться, что из перечисленных бенефитов мало что маст-хэв, а большинству людей наверное большинство из этого и не нужно толком. Мне кажется что на сцене DVCS пока что безоговорочно лидирует GitHub (мне больше нравится Mercurial, но увы...)
Мне понравилось, как вы в DVCS записали хостинг репозиториев. Наверное, что-то в этом есть трендовое :)
GitHub может и лидирует (мода), но bitbucket весьма неплох.
Ага, ну ясно, bisect нету, rebase нету, patch queues нету. Населена роботами. Зато есть нафиг не нужный клиент для iPad, юзерские аккаунты и прочая трасца.
Да уж, у меня тоже сложилось впечатление, что некоторые возможности сделаны из маркетинговых соображений. А еще на onVeracity.com платный аккаунт стоит всего-то 20 (!) долларов на пользователя в месяц.
Обожаю этот жанр тупых переводов англоязычных статьей, когда автор при этом не в зуб ногой о теме постинга и даже не пробовал :)
Мне жаль, что вы так думаете. Во-первых англоязычных статей про Veracity попросту нет (только на Википедии два абзаца и указанная мной книга). Это легко можно проверить в Google. А во-вторых, поскольку эта система не настолько популярна, как Git, по ней не так уж много документации. Моей целью было собрать имеющуюся информацию, чтобы другие могли получить первое представление о Veracity. И к тому же, в-третьих, стали бы вы использовать в серьезных рабочих проектах ПО, качество и фунциональность которого никем не подтверждены?
Децентрализованная база данных репозитория.

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

И как там с производительностью?
GUI клиента типа Tortoise пока нет для нее?
Вообще на сайте написано, что уже с прошлого года в Windows-установщике добавлена графическая оболочка наподобие Tortoise SVN. Мне не на чем проверить это ибо у меня Linux.
То есть, автор статьи не предоставил никакой новой идеологии.
Просто чтото похожее, где некоторые функции сделаны чуть иначе?
Какая печаль.
Еще автор не упомянул о встроенных wiki и task list
Ух… Всем спасибо за отзывы и комментарии! Главный вывод, который я для себя сделал — нужно досконально изучить Mercurial. ;)
Действительно попробуйте. У меня сложилось впечатление, что именно его особенности вам пришлись бы очень кстати. Тем более с позиции сравнения с уже двумя известными вам системами.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.