Re[4]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 26.12.14 17:47
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

Н> .>Можно ещё добавить, что в том же hg тоже хеши, но структура репозитория "классическая" — revlog с патчами и магия с диффами для восстановления исторического контента.

Н> В Git'е в .pack-файлах хранятся те же диффы.
Далеко не те же. pack-файл это просто архив всех объектов, он пакует похожие файлы, а не историю каждого конкретного файла. И можно перепаковыварь в любое время. В отличие от appendonly-монстра revlog. А суть в том, что наличие pack-файлов не влияет на дизайн системы, это просто деталь имплементации, более экономное сохранения тех же объектов на диск.

Н> .>Поэтому в hg много сложностей с реализацией некоторых фич. Скажем, аналог rebase довольно неуклюжий, с какими-то бэкапами. В git всё тот же граф объектов, бранчи, reflog.

Н> Не поэтому. Основные сложности из-за того, что, во-первых, Revlog'и -- они Append-Only, и, во-вторых, между Revlog'ами есть нетривиальные зависимости, которые не позволяют просто "удалять" чейнджсеты.
Во-во. Куча придуманных сложностей, с которыми надо бороться.

Н> Сейчас в Mercurial дописывают Changeset Evolution, который суть "DVCS для DVCS" и помогает обмениваться историей изменения истории.

А какой юзкейс для этого? Чем это лучше тривиального "поместить reflog в git"?
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Pro Git: Snapshots, Not Differences
От: Нахлобуч Великобритания https://hglabhq.com
Дата: 29.12.14 12:12
Оценка:
Здравствуйте, ., Вы писали:

Н>> .>Можно ещё добавить, что в том же hg тоже хеши, но структура репозитория "классическая" — revlog с патчами и магия с диффами для восстановления исторического контента.

Н>> В Git'е в .pack-файлах хранятся те же диффы.
.>Далеко не те же. pack-файл это просто архив всех объектов, он пакует похожие файлы, а не историю каждого конкретного файла. И можно перепаковыварь в любое время. В отличие от appendonly-монстра revlog. А суть в том, что наличие pack-файлов не влияет на дизайн системы, это просто деталь имплементации, более экономное сохранения тех же объектов на диск.

Выделил курсивом ключевую часть. "Патчи и магия с диффами" в Гите присутствует практически в той же степени, что и везде. С тем,что .pack-файлы -- деталь реализации, знать о которой остальной системе необязательно, соглашусь.

Н>> .>Поэтому в hg много сложностей с реализацией некоторых фич. Скажем, аналог rebase довольно неуклюжий, с какими-то бэкапами. В git всё тот же граф объектов, бранчи, reflog.

Н>> Не поэтому. Основные сложности из-за того, что, во-первых, Revlog'и -- они Append-Only, и, во-вторых, между Revlog'ами есть нетривиальные зависимости, которые не позволяют просто "удалять" чейнджсеты.
.>Во-во. Куча придуманных сложностей, с которыми надо бороться.

Revlog был придуман для экономии и минимизации I/O: например, в Git простой просмотр списка коммитов -- O(n), в Mercurial -- O(1). То же и для реконструкции любой ревизии файла.

Н>> Сейчас в Mercurial дописывают Changeset Evolution, который суть "DVCS для DVCS" и помогает обмениваться историей изменения истории.

.>А какой юзкейс для этого? Чем это лучше тривиального "поместить reflog в git"?

Так не взлетит, потому что Changeset Evolution -- это метаистория, если угодно, и должна находиться "над" самой историей.

Юэкейc, в принципе, один: надежный обмен историей изменения истории в распределенном окружении. Например, что делать, если один разработчик сделал "hg commit --amend" для чейнджсета deadc0de, другой его же заребэйзил поверх badf000d, третий смерджил его с c0dec0de, четвертый этот чейнджсет удалил, а пятый -- просто сделал следующий коммит "поверх"? Врукопашную, без поддержки со стороны самой VCS, распутать, что же должно в итоге происходить, будет очень непросто.
HgLab: Mercurial Server and Repository Management for Windows
Re[6]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 29.12.14 12:54
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

Н>>> .>Можно ещё добавить, что в том же hg тоже хеши, но структура репозитория "классическая" — revlog с патчами и магия с диффами для восстановления исторического контента.

Н>>> В Git'е в .pack-файлах хранятся те же диффы.
.>>Далеко не те же. pack-файл это просто архив всех объектов, он пакует похожие файлы, а не историю каждого конкретного файла. И можно перепаковыварь в любое время. В отличие от appendonly-монстра revlog. А суть в том, что наличие pack-файлов не влияет на дизайн системы, это просто деталь имплементации, более экономное сохранения тех же объектов на диск.
Н>Выделил курсивом ключевую часть. "Патчи и магия с диффами" в Гите присутствует практически в той же степени, что и везде. С тем,что .pack-файлы -- деталь реализации, знать о которой остальной системе необязательно, соглашусь.
Ещё раз. Это не патчи с диффами, а специально адаптированный(е) алгоритм(ы) компрессии специфичных (сильно похожих) данных. Delta compression.

Objects in the repository that have not yet been delta-compressed ("loose objects") are compared against a heuristically chosen subset of all other objects, and the common data and differences are concatenated into a "pack file" which is then compressed using conventional methods

Притом, если я правильно понял это, git использует немного разные подходы к формированию pack-файлов во время gc и во время pull/fetch операций (передача объектов между репами).
Сравни это со ртутным append-only revlog для каждого отдельного файла.

Н>>> .>Поэтому в hg много сложностей с реализацией некоторых фич. Скажем, аналог rebase довольно неуклюжий, с какими-то бэкапами. В git всё тот же граф объектов, бранчи, reflog.

Н>>> Не поэтому. Основные сложности из-за того, что, во-первых, Revlog'и -- они Append-Only, и, во-вторых, между Revlog'ами есть нетривиальные зависимости, которые не позволяют просто "удалять" чейнджсеты.
.>>Во-во. Куча придуманных сложностей, с которыми надо бороться.
Н>Revlog был придуман для экономии и минимизации I/O: например, в Git простой просмотр списка коммитов -- O(n), в Mercurial -- O(1). То же и для реконструкции любой ревизии файла.
Не понял. Список коммитов невозможно построить быстрее чем за O(n) в принципе.
Реконструкция ревизии — тоже не понял. Зачем в git что-то реконструировать? Поиск по хеш-таблице объектов, O(1) от числа файлов; плюс распаковать, O(n) от размера файла.

Н>>> Сейчас в Mercurial дописывают Changeset Evolution, который суть "DVCS для DVCS" и помогает обмениваться историей изменения истории.

.>>А какой юзкейс для этого? Чем это лучше тривиального "поместить reflog в git"?
Н>Так не взлетит, потому что Changeset Evolution -- это метаистория, если угодно, и должна находиться "над" самой историей.
git позволяет иметь несколько независимых историй (разные, независимые DAG) в одном репо. Поэтому DAG для reflog это будет история "главного" DAG. Рекурсия, однако.
Например, таким образом реализованы git notes, — "изменяемая" метаинформация поверх неизменяемых объектов.

Н>Юэкейc, в принципе, один: надежный обмен историей изменения истории в распределенном окружении. Например, что делать, если один разработчик сделал "hg commit --amend" для чейнджсета deadc0de, другой его же заребэйзил поверх badf000d, третий смерджил его с c0dec0de, четвертый этот чейнджсет удалил, а пятый -- просто сделал следующий коммит "поверх"? Врукопашную, без поддержки со стороны самой VCS, распутать, что же должно в итоге происходить, будет очень непросто.

И как же именно VCS может помочь? Особенно DVCS?
С т.з. git это будут разные коммиты, мержи и разрешай конфликты как обычно. Правда из коробки он никак не обозначит, что "вот эти коммиты один и тот же changeset". Хотя, надо ещё понять а что же это такое "один и тот же changeset".
Кстати в том же gerrit это просто реализовано как тег внутри commit message. Но gerrit это уже не Distributed.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 29.12.14 23:24
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

Н>Revlog был придуман для экономии и минимизации I/O

Кстати, как они прогадали с оптимизацией I/O под sequential read, ВНЕЗАПО появились и безумно подешевели SSD.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Pro Git: Snapshots, Not Differences
От: Sergey J. A. Беларусь  
Дата: 30.12.14 08:30
Оценка:
Здравствуйте, Clerk, Вы писали:

SJA>>З.Ы. Раз уж коснулось. Откуда в комите номер билда? Или git log -S ищет и по тегам?

C>-S ищет по содержимому коммита.

А как номер билда в коммит попадает? Ведь неизвестно какой коммит будет последним перед сборкой билда. Опять же, что делать, если на одном комите несколько билдов было построено...
Re[7]: Pro Git: Snapshots, Not Differences
От: Clerk  
Дата: 30.12.14 09:13
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

SJA>А как номер билда в коммит попадает? Ведь неизвестно какой коммит будет последним перед сборкой билда. Опять же, что делать, если на одном комите несколько билдов было построено...

Номер билда — это автоинкремент, файл этот меняется программой сборки, она же его и коммитит, вешает таг и потом проект собирает. Т.е. сборка — это тоже коммит и таг от юзера по имени build server.
Несколько разных билдов на одном коммите проблемой не являются, разве что немного места занимают. Впрочем, можно добавить проверку что после последнего билда (коммита) ничего не менялось и не собирать новый билд в таком случае.
Re[8]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 30.12.14 21:34
Оценка:
Здравствуйте, Clerk, Вы писали:

C> SJA>А как номер билда в коммит попадает? Ведь неизвестно какой коммит будет последним перед сборкой билда. Опять же, что делать, если на одном комите несколько билдов было построено...

C> Номер билда — это автоинкремент, файл этот меняется программой сборки, она же его и коммитит, вешает таг и потом проект собирает. Т.е. сборка — это тоже коммит и таг от юзера по имени build server.
C> Несколько разных билдов на одном коммите проблемой не являются, разве что немного места занимают. Впрочем, можно добавить проверку что после последнего билда (коммита) ничего не менялось и не собирать новый билд в таком случае.
Тогда
git log -S"1845" -- build_no.txt
будет выдавать не то. Надо первый коммит брать, а не последний. --reverse как минимум.
А всё-таки... Что там такого неправильного у вас в svn репозитории? Ведь git-svn поддерживает теги, замапить только надо. Он не выкачивает всю историю тега, а определяет, что оно — копия транка.
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Pro Git: Snapshots, Not Differences
От: Clerk  
Дата: 05.01.15 07:52
Оценка:
Здравствуйте, ., Вы писали:

.>А всё-таки... Что там такого неправильного у вас в svn репозитории? Ведь git-svn поддерживает теги, замапить только надо. Он не выкачивает всю историю тега, а определяет, что оно — копия транка.

А вот люди говорят, что не всё так просто:

Since tags in svn are real branches...

, то, судя по всему, будут выкачаны как бранчи. В целом, конечно, можно добиться переделывания svn тагов/бранчей в настоящие таги git, но зачем.
Re[10]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 05.01.15 10:18
Оценка:
Здравствуйте, Clerk, Вы писали:

.>>А всё-таки... Что там такого неправильного у вас в svn репозитории? Ведь git-svn поддерживает теги, замапить только надо. Он не выкачивает всю историю тега, а определяет, что оно — копия транка.

C>А вот люди говорят, что не всё так просто:

Since tags in svn are real branches...

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

Да какая разница? С т.з. гита — единственное отличие бранча от тега — в тег нельзя коммитить. А с т.з. как и что выкачивается — без разницы.
Что конкретно ты подразумеваешь под "будут выкачаны как бранчи"?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Pro Git: Snapshots, Not Differences
От: Clerk  
Дата: 05.01.15 10:33
Оценка:
Здравствуйте, ., Вы писали:

.>Что конкретно ты подразумеваешь под "будут выкачаны как бранчи"?

Так как исходников много, то это займёт уйму времени на выкачивание.
Re[12]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 05.01.15 13:48
Оценка:
Здравствуйте, Clerk, Вы писали:

.>>Что конкретно ты подразумеваешь под "будут выкачаны как бранчи"?

C>Так как исходников много, то это займёт уйму времени на выкачивание.
Ещё раз. git-svn не "выкачивает бранчи", а определяет, что данный бранч/тег был создан копированием определённой svn-ревизии транка/бранча/тега и делает аналогичное действие в гит-репозитории.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: Pro Git: Snapshots, Not Differences
От: Clerk  
Дата: 05.01.15 14:01
Оценка:
Здравствуйте, ., Вы писали:

C>>Так как исходников много, то это займёт уйму времени на выкачивание.

.>Ещё раз. git-svn не "выкачивает бранчи", а определяет, что данный бранч/тег был создан копированием определённой svn-ревизии транка/бранча/тега и делает аналогичное действие в гит-репозитории.
Вот сейчас добавил в config выкачивание тагов:
[svn-remote "svn"]
    tags = tags/*:refs/remotes/svn/tags/*


Запускаю git svn fetch и вижу, что таги из svn выкачиваются как бранчи в svn/tags. Да, согласен, лишние исходники оно не тянет, но зачем мне тысячи бранчей в разделе svn?
Re[14]: Pro Git: Snapshots, Not Differences
От: . Великобритания  
Дата: 05.01.15 16:54
Оценка:
Здравствуйте, Clerk, Вы писали:

C>>>Так как исходников много, то это займёт уйму времени на выкачивание.

.>>Ещё раз. git-svn не "выкачивает бранчи", а определяет, что данный бранч/тег был создан копированием определённой svn-ревизии транка/бранча/тега и делает аналогичное действие в гит-репозитории.
C>Вот сейчас добавил в config выкачивание тагов:
C>
[svn-remote "svn"]
C>    tags = tags/*:refs/remotes/svn/tags/*
C>


C>Запускаю git svn fetch и вижу, что таги из svn выкачиваются как бранчи в svn/tags. Да, согласен, лишние исходники оно не тянет, но зачем мне тысячи бранчей в разделе svn?

Чтобы мгновенно делать "git checkout <build_number>". По-моему оно того стоит.
А что такого? Один бранч занимает 41 байт. Жалко что-ли? Если мешаются в списке, можешь в другой ref-namespace замапить. "tags/*:refs/releases/*"
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.