Комментарии 70
Не такая уж она и новая. У меня уже больше полугода на полке стоит их «Version Control by Example», очень неплохая и интересная книга. Когда-то они их бесплатно высылали, когда только дебютировали. Но пока так и не нашел особых преимуществ перед git. Из недостатков — пока что слабая интеграция с IDE.
Ну, начинание ок, но при наличии гита…
А мне как-то все это сильно напоминает меркуриал. Но в целом принципиально нового не услышал.
Вообще, хотелось бы почитать сравнение именно с этой VCS.
Вообще, хотелось бы почитать сравнение именно с этой VCS.
На главной странице проекта есть сравнительная таблица veracity-scm.com/
вы пользуетесь этой системой контроля версий?
как у нее со скоростью по сравнению с git? лучше/хуже merge?
и для чего поддержка нескольких хэш функций?
как у нее со скоростью по сравнению с git? лучше/хуже merge?
и для чего поддержка нескольких хэш функций?
Если честно, то сам пользуюсь Git. Для моих нужд она сыровата и лично мне не хватает staging. Однако мне нравятся некоторые идеи, заложенные в ней и я просто слежу за ее развитием. По поводу хэш-функций, например, SHA-2 отличается от SHA-1 тем, что для нее пока что не обнаружено коллизий, то бишь возможно их значительно меньше.
а в Git разве стоит эта проблема? коллизия в репозитории — это что-то очень маловероятное, на мой взгляд.
Нет, не стоит. По поводу коллизий это было лишь предположение.
Тут ещё дело в том, что хэш часто используется для подтверждения аутентичности коммита: если ченджсет существовал в репозитории вчера с таким хэшем, то почти наверняка завтра можно будет сказать, что это тот же самый ченджсет.
Но, если вспомнить проблему со взломом серверов kernel.org — команда разработчиков проверяла достоверность по каким-то своим цифровым подписям, не доверяя хэшу.
(хотя я не совсем детально в это всё вникал, возможно я и наговорил какую-то фигню :-)
Но, если вспомнить проблему со взломом серверов kernel.org — команда разработчиков проверяла достоверность по каким-то своим цифровым подписям, не доверяя хэшу.
(хотя я не совсем детально в это всё вникал, возможно я и наговорил какую-то фигню :-)
Нифига не понял. Очевидно, что в хеш-функции M бит в N число коллизий равно exp(M-N).
с каких пор отсутствие механизма блокировки файлов стало недостатком? Всю жизнь думал что слияние — это плюс, устраняющий недостаток, в лице блокировки.
Это не недостаток, но для бинарных файлов блокировка удобнее. Лично мне часто приходится редактировать схемы баз данных для разрабратываемого приложения. Эти схемы хранятся в бинарном виде. Хорошо, что используемая в проекте Subversion это поддерживает.
Поясните немного про блокировку. Я правильно понял, что если вы заблокируете файл, никто другой не сможет запушить изменения в этот файл, пока вы его не разблокируете?
Как тогда будет выглядеть ситуация: сфетчил репозиторий, локально сделал с десяток коммитов, пушишь — а там файл заблокирован? В git вместо блокировки был бы конфликт, а тут как?
Как тогда будет выглядеть ситуация: сфетчил репозиторий, локально сделал с десяток коммитов, пушишь — а там файл заблокирован? В git вместо блокировки был бы конфликт, а тут как?
Я не очень понимаю, как децентрализованность вяжется с блокировками.
Ведь блокировка будет работать только если есть связь со всеми остальными репозиториями — иначе как там заблокировать файл. А значит система получается очень махрово централизованная — причем связь должна быть не просто с центральным сервером, а каждого репозитория с каждым. Имхо это еще хуже.
Или я что-то упустил?
Ведь блокировка будет работать только если есть связь со всеми остальными репозиториями — иначе как там заблокировать файл. А значит система получается очень махрово централизованная — причем связь должна быть не просто с центральным сервером, а каждого репозитория с каждым. Имхо это еще хуже.
Или я что-то упустил?
В документации написано, что для создания блокировки необходим доступ в сеть, то бишь действительно будет осуществляться соединение с удаленным сервером и передача ему информации о блокировке. Если вы используете блокировки, то теряете децентрализованность, тут уж никуда не деться.
Значит, это не децентрализованная система, а очень централизованная, где все должны сидеть в одной комнате, чтобы нормально работать друг с другом.
Представьте, один разработчик из команды работает на своем ноутбууке и полетел на конференцию. Пока он летит, вы работать не можете — т.к. он все сети и непонятно как сделать блокировку. Либо на это время вы должны исключить его из списка блокирования. Но тогда получается, что у вас по сути нет блокировок! Ведь если он внесет какие-то изменения в систему, то он это сделает без учета блокировок, что может привести к конфликтам. А система, похоже, построена на идее, что блокировка спасет.
Вообще, для понимания какие проблемы могут возникать в таких вещах (и многих других) есть замечательная CAP-теорема Брюера:
Как говорится: выберите 2 из 3. Оставшимся придется пожертвовать.
Несколько человек, работающих над одним проектом, это уже распределенная система, даже если они никакую VCS не используют, а тупо заливают файлы по FTP. Это так уже потому, что у каждого из них «чуть свой» вариант проекта. Никакая VCS не сможет обеспечить решение всех трех проблем сразу, поэтому не нужно пытаться изобрести суперсистему, которая всех сделает счастливыми. Лучше сразу изобрести вечный двигатель. Задача VCS — облегчить рутинные проблемы разработчиков.
Каждая из них это делает по-своему:
— CVS может это решить с помощью блокировок. То есть корректность и устойчивость к сбоям узлов обеспечивается ценой доступности для разработчиков. Если возникает конфликт одновременного изменения, то кто-то должен ждать — то есть для него персонально система не доступна.
— GIT жертвует корректностью, зато система всегда доступна и устойчива к выпадению и появлению узлов. Но при этом конфликтные изменения дадут вам проблему при объединении веток. Автоматически это не решается — требуется вручную просмотреть изменения и решить какие и как принять.
— Veracity (как написано) выбирает корректность и доступность, значит она не устойчива к сбоям узлов. Зато в системе вы сможете бесконфликтно и надежно работать. Ровно до тех пор, пока не выпадет из работы один из узлов. После чего имеющиеся на нем конфликтные изменения нужно будет руками сливать. Просто вернуться в строй он не сможет.
Из всех рассмотренных вариантов наиболее адекватным мне кажется подход 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: отдельное спасибо минусовавшим, которые не разобравшись жмут на кнопку. Удачного вам дня.
$ 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 при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.
Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.
Подытоживая: я не говорил, что гит сохраняет информацию о переименованиях, но я говорил, что никакого «удалить и потом создать такой же» там не происходит, а всё несколько более интеллектуально.
Изначальная фраза, которую я комментировал:
> Git при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.
Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.
Подытоживая: я не говорил, что гит сохраняет информацию о переименованиях, но я говорил, что никакого «удалить и потом создать такой же» там не происходит, а всё несколько более интеллектуально.
Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.
Нет. Git отслеживает изменения _содержимого_ файлов, а не сами файлы. Вы можете скопировать файл 10 раз, и это не приведет к увеличению репозитория, в котором однажды этот файл был проиндексирован. Будут лишь созданы ссылки на ранее сохраненный объект, идентифицируемый хешем от содержимого файла. С удалением файла и последующим добавлением — та же самая ситуация (поскольку из истории объект не удалялся, при повторном добавлении его в репозиторий будет лишь создана ссылка на старый объект).
Поправка: Mercurial будет смотреть на сходство, если использовать
hg addremove --similarity.
попробуйте git gc размер должен уменьшиться
Эм, куда ему ещё уменьшаться? Я же показал своим примером, что содержимое файла дважды не пишется. М?
git gc почистит ссылки на отсутствующие объекты www.kernel.org/pub/software/scm/git/docs/git-gc.html
Я понимаю это. Но откуда в данном случае им вообще возникнуть?
ps: я бы даже сказал, что будут почищены недоступные объекты, которые могут возникнуть в случае git reset, удаления несмердженного бренча, итд
Поясните, что именно вы хотели сказать, потому как на данном этапе это не совсем ясно.
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
Вот вам пример:
$ 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 в позикс-системах — это тоже дешевая операция, так как большинство информации репозитория шарится с помощью хардлинков файловой системы.
НЛО прилетело и опубликовало эту надпись здесь
В чем цель создания этого проекта? Какую проблему он решает? Какие задачи ставят себе разработчики?
У Линуса была совершенно четкая цель — быстро сделать нормальную удобную децентрализованную систему для разработки ядра Линукс. Все понимали что и для чего делается — в итоге создали хорошую cистему.
Здесь я пока что вижу «давайте сделаем как в git, только по-другому».
У Линуса была совершенно четкая цель — быстро сделать нормальную удобную децентрализованную систему для разработки ядра Линукс. Все понимали что и для чего делается — в итоге создали хорошую cистему.
Здесь я пока что вижу «давайте сделаем как в git, только по-другому».
Децентрализованная база данных репозиторияПолучается, наоборот — в Veracity централизованная на все проекты, а в git — на каждый в отдельности.
К слову, в git можно настроить расположение .git папки на своё усмотрение, не обязательно хранить её внутри проекта.
Оффтоп: у меня одного таблица команд кривая? Первый столбец ровно 2 символа шириной.
Такое ощущение, что они изобрели mercurial. Из перечисленного он может все, кроме раздельного хранения служебной информации. Но это достаточно спорная фича — да, можно делать несколько директоий с низким оверхедом, зато эти директории нельзя перемещать средствами файловой системы.
На самом деле я еще и не совсем уверен нужно ли было использовать вообще SQLite для создания подобных систем. Git вот абсолютно спокойно обходится простыми текстовыми файлами.
В меркуриале это тоже есть, только в немного другом виде. Здесь сделано больше как в Fossil (да и SQLite как back-end тоже используют).
НЛО прилетело и опубликовало эту надпись здесь
Должен признаться, что из перечисленных бенефитов мало что маст-хэв, а большинству людей наверное большинство из этого и не нужно толком. Мне кажется что на сцене DVCS пока что безоговорочно лидирует GitHub (мне больше нравится Mercurial, но увы...)
Ага, ну ясно, bisect нету, rebase нету, patch queues нету. Населена роботами. Зато есть нафиг не нужный клиент для iPad, юзерские аккаунты и прочая трасца.
Обожаю этот жанр тупых переводов англоязычных статьей, когда автор при этом не в зуб ногой о теме постинга и даже не пробовал :)
Мне жаль, что вы так думаете. Во-первых англоязычных статей про Veracity попросту нет (только на Википедии два абзаца и указанная мной книга). Это легко можно проверить в Google. А во-вторых, поскольку эта система не настолько популярна, как Git, по ней не так уж много документации. Моей целью было собрать имеющуюся информацию, чтобы другие могли получить первое представление о Veracity. И к тому же, в-третьих, стали бы вы использовать в серьезных рабочих проектах ПО, качество и фунциональность которого никем не подтверждены?
Децентрализованная база данных репозитория.
Это может быть как плюсом, так и минусом, поэтому наилучшим вариантом была бы поддержка обоих методов хранения служебной информации.
GUI клиента типа Tortoise пока нет для нее?
То есть, автор статьи не предоставил никакой новой идеологии.
Просто чтото похожее, где некоторые функции сделаны чуть иначе?
Какая печаль.
Просто чтото похожее, где некоторые функции сделаны чуть иначе?
Какая печаль.
Еще автор не упомянул о встроенных wiki и task list
Ух… Всем спасибо за отзывы и комментарии! Главный вывод, который я для себя сделал — нужно досконально изучить Mercurial. ;)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Встречаем Veracity — новую распределенную систему контроля версий