Как известно git немного извращённая система хранения версий файлов, но не директорий, последних попросту нет. Размышлял про синхронизацию файлов и мне в голову пришла мысль, что git то ведь ставит коммит на файлы, а не файл.
Можно, конечно, ещё раз извратиться и добавлять на сцену по одному файлу, потом делать коммиты. Но суть в том, что сточки зрения синхронизации именно файлов это не самая лучшая идея.
Логичнее применять принцип CRUD именно к файлу, а не файлам, тогда жизненный цикл каждого файла будет выглядеть как:
---------------
Create
---------------
Read или Update
---------------
Delete
---------------
И я не утверждаю, что git не может показывать как изменялся каждый файл в отдельности, здесь дело именно в изначальном подходе. Почему ориентированность именно на файлы? Значит подразумевается, что все файлы в хранилище это некая единая сущность, хотя на самом деле это может быть не так.
Вопрос отчасти философский, но что если бы изначально был заложен принцип изменения каждого файла в отдельности. Ведь тогда бы и программисты смотрели на деревья изменения каждого файла в отдельности, а не на одно дерево изменения файлов.
Собственно откуда такая мысль. Для проекта могут быть важны теги завершённости программы и всё в таком роде. Но как никто не мешает делать коммиты под изменения каждого файла, так никто не мешает выстроить изменения файлов в единую цепочку и привязывать тег к изменению последнего файла.
Другое дело для синхронизации привязка ко множеству изменений файлов практически ничего не даёт. Выгоднее отслеживать каждый файл в отдельности, это и для контроля повреждений полезнее. А самое главное в системе изменения версий для некоторых это вовсе не комментарий в стиле "ля ля ля", а просто сохранение новых версий файлов.
Фактически многим было бы достаточно просто одной кнопки "сохранить в хранилище" и всё, а если так уж нужен коммит, то просто автоматически ставить номер текущего изменения, который каждый раз будет увеличиваться на один.
Опять же если ориентироваться на файл, то можно было бы легко разделить его или группу файлов с хранилищем создав для них другое хранилище или слить файлы из разных хранилищь на основе тех же дат и времени изменения.
Вот и выходит, инструмент есть, он работает, но провоцирует работу с собой именно так, а не иначе. Соответственно все механизмы заточены на другой стиль работы, если не пожертвовать удобством или дописать свой инструмент над этим.
Да и в принципе это размышления про синхронизацию файлов. Можно ли сказать, что уровень удобства с системами хранения версий достиг максимума. Лично я такого сказать не могу.
А между тем некоторые программы отличаются не самими данными, а способом работы с ними, при этом разница колоссальна, что одно кажется по сравнению с другими некстгеном.
Здравствуйте, velkin, Вы писали:
V>Как известно git немного извращённая система хранения версий файлов, но не директорий, последних попросту нет. Размышлял про синхронизацию файлов и мне в голову пришла мысль, что git то ведь ставит коммит на файлы, а не файл.
Потому что изменений, которые затрагивают один файл, мало от общего числа, а атомарность коммита требует иметь возможность описывать состояние всех файлов.
V>Можно, конечно, ещё раз извратиться и добавлять на сцену по одному файлу, потом делать коммиты. Но суть в том, что сточки зрения синхронизации именно файлов это не самая лучшая идея.
А при чём тут синхронизация?
V>И я не утверждаю, что git не может показывать как изменялся каждый файл в отдельности, здесь дело именно в изначальном подходе. Почему ориентированность именно на файлы? Значит подразумевается, что все файлы в хранилище это некая единая сущность, хотя на самом деле это может быть не так.
Где "это" не так, можно разделить на разные коммиты.
V>Вопрос отчасти философский, но что если бы изначально был заложен принцип изменения каждого файла в отдельности. Ведь тогда бы и программисты смотрели на деревья изменения каждого файла в отдельности, а не на одно дерево изменения файлов.
Спасибо, намучались с этим в CVS. Реально больше не хочу.
V>Собственно откуда такая мысль. Для проекта могут быть важны теги завершённости программы и всё в таком роде. Но как никто не мешает делать коммиты под изменения каждого файла, так никто не мешает выстроить изменения файлов в единую цепочку и привязывать тег к изменению последнего файла.
V>Другое дело для синхронизации привязка ко множеству изменений файлов практически ничего не даёт. Выгоднее отслеживать каждый файл в отдельности, это и для контроля повреждений полезнее.
Кому выгоднее?
Чем полезнее?
V>Фактически многим было бы достаточно просто одной кнопки "сохранить в хранилище" и всё, а если так уж нужен коммит, то просто автоматически ставить номер текущего изменения, который каждый раз будет увеличиваться на один.
Используйте CVS, если оно устраивает. Или даже RCS, там ещё проще по каждому файлу что-то делать.
Почему бы и нет?
V>А между тем некоторые программы отличаются не самими данными, а способом работы с ними, при этом разница колоссальна, что одно кажется по сравнению с другими некстгеном.
Здравствуйте, netch80, Вы писали:
V>>Другое дело для синхронизации привязка ко множеству изменений файлов практически ничего не даёт. Выгоднее отслеживать каждый файл в отдельности, это и для контроля повреждений полезнее. N>Кому выгоднее? N>Чем полезнее?
Выгоднее с точки зрения синхронизации файлов и массовой системы хранения версий, которая может покрывать весь диск из миллионов файлов. В перспективе из миллиардов и более.
N>Используйте CVS, если оно устраивает.
Это система хранения версий предыдущих поколений, и естественно централизованная. Тоже самое с SVN. Вот об этом я и говорю, по факту git гораздо лучше, он децентрализованный. Но идеален ли он, что не нужно создавать следующее поколение систем хранения версий? Причём я бы предпочёл не только файлов, но и папок без всяких .gitkeep и прочих извращений.
Я бы сказал, что git это то, что работает, но до определённого предела и не так, чтобы особо удобно. А сверху ещё и навязывается идеология использования, хотя командами его можно использовать иначе.
Здравствуйте, velkin, Вы писали:
V>Почему коммит git на файлы, а не файл?
Потому что в общем случае атомарное изменение кодовой базы с сохранением инвариантов (компилируемость, прохождение тестов) — это изменение нескольких файлов, а не одного.
Если производя простой рефакторинг типа переименования ты будешь коммитить затронутые файлы по очереди, то у тебя в истории будут заведомо некорректные промежуточные состояния.
Здравствуйте, velkin, Вы писали:
v> N>Кому выгоднее? v> N>Чем полезнее? v> Выгоднее с точки зрения синхронизации файлов и массовой системы хранения версий, которая может покрывать весь диск из миллионов файлов. В перспективе из миллиардов и более.
Ты по-моему немного плохо понимаешь как устроен git. Во-первых, он по большому счёту оперирует не файлами а контентом: "git — the stupid content tracker". Во-вторых, всякие git vfs миллионами файлами оперировать уже умеют.
v> Это система хранения версий предыдущих поколений, и естественно централизованная. Тоже самое с SVN. Вот об этом я и говорю, по факту git гораздо лучше, он децентрализованный. Но идеален ли он, что не нужно создавать следующее поколение систем хранения версий? Причём я бы предпочёл не только файлов, но и папок без всяких .gitkeep и прочих извращений.
Папки это не контент, а способ его организации. Термина такого нет внутрях гита, он оперирует деревьями (tree) и содержимым (blob).
v> Я бы сказал, что git это то, что работает, но до определённого предела и не так, чтобы особо удобно. А сверху ещё и навязывается идеология использования, хотя командами его можно использовать иначе.
Да, его высокоуровневые команды заточены под самый частый случай применения — как систему управления исходниками. Но поверх можно накручивать более уникальные случаи. Но и не унивесальный всемогутер, ясен пень.
Здравствуйте, Qbit86, Вы писали:
Q>Если производя простой рефакторинг типа переименования ты будешь коммитить затронутые файлы по очереди, то у тебя в истории будут заведомо некорректные промежуточные состояния.
Вот принципы из книги Мартина Фаулера "Архитектура корпоративных программных приложений" для работы с данными. Этапы создания файлов пропустил.
Коммиты по файлам группой:
изменение 001 файла 1-+
изменение 002 файла 2 | коммит 1 (правильное состояние)
изменение 003 файла 1-+
изменение 004 файла 3-+
изменение 005 файла 2 | коммит 2 (правильное состояние) тег 0.1
изменение 006 файла 1-+
Коммиты по каждому файлу:
изменение 001 файла 1
изменение 002 файла 2
изменение 003 файла 1-+ коммит 1 (правильное состояние)
изменение 004 файла 3
изменение 005 файла 2
изменение 006 файла 1-+ коммит 2 (правильное состояние) тег 0.1
Мы можем смотреть на тоже самое по другому и тогда оно станет уже не тем же самым, а иной абстракцией. Отсюда можно вывести, что коммит это ручной ввод, тогда как сами файлы уже могли меняться несколько раз. Я могу коммитить то самое неправильное состояние вручную, это к делу вообще никак не относится. Важно то, как я буду всё это воспринимать.
Если я воспринимаю изменения по каждому файлу, тогда для меня очевидной будет следующая схема просмотра:
изменения файла 1:
изменение 001 файла 1
изменение 003 файла 1-+ коммит 1 (правильное состояние)
изменение 006 файла 1-+ коммит 2 (правильное состояние) тег 0.1
изменения файла 2:
изменение 002 файла 2
изменение 005 файла 2
изменения файла 3:
изменение 004 файла 3
Тогда как ориентируясь на групповое изменения файлов не факт, что я захочу отдавать git команды, чтобы видеть изменения именно вот так. При открытие же файла картина будет выглядеть как-то так.
Конечно, я могу получить эту информацию из git, но изначально он и в особенности gui к нему, мне суют совершенно другое. И выше уже описал случай, когда людям нужно просто сохраниться или синхронизироваться. Может даже делать это автоматически. Вместо этого их заставляют играть в угадайку названия коммита.
Была уже тема про то, что по названию коммита нельзя отследить изменения, то есть кроме важных тегов всё это не сильно нужно. В конечном итоге смотреть всё равно будешь по изменениям и кто их вносил, а не на то, что программист при этом написал. Здесь и проблемы, что всех нужно обучать писать правильные названия и всё в таком роде.
А теперь ещё одно понятие, разделение и слияние файлов по разным хранилищам.
хранилище 01
изменения файла 1:
изменение 001 файла 1
изменение 003 файла 1
изменение 006 файла 1
изменения файла 2:
изменение 002 файла 2
изменение 005 файла 2
изменения файла 3:
изменение 004 файла 3
хранилище 02
.
Убираем файл 01 в хранилище 02.
хранилище 01
изменения файла 2:
изменение 002 файла 2
изменение 005 файла 2
изменения файла 3:
изменение 004 файла 3
хранилище 02
изменения файла 1:
изменение 001 файла 1
изменение 003 файла 1
изменение 006 файла 1
Если не завязывать коммиты на группу файлов, то эта операция кажется более естественной, как и слияние файлов из нескольких хранилищ в одно.
Здравствуйте, velkin, Вы писали:
V>Как известно git немного извращённая система хранения версий файлов
Нет, не файлов. git задуман как система хранения версий исходных кодов программ. И ориентирован в первую очередь на это. То что иногда его применяют для чего-то другого — это бывает, но не надо удивляться, что поведение не всегда такое как тебе при этом хочется.
Для исходников более важно не то, как конкретный файл изменялся, а то, какое суммарное изменение делалось. Потом основной элемент — changeset, набор изменений, которые внесли какую-то правку, и он может включать несколько файлов.
Идея атомарных коммитов, включающих несколько файлов сразу, появилась давно, еще до гита. Потому что еще раньше были системы контроля версий, работающие с файлами по одиночке, и это было плохо и неудобно.
Здравствуйте, fmiracle, Вы писали:
F>Нет, не файлов. git задуман как система хранения версий исходных кодов программ. И ориентирован в первую очередь на это.
Git создал Линус Торвальдс для ядра Linux. Очевидно и работа заточена под это дело. С каким бы проектом у себя не работал, будешь работать как с ядром Linux. А про ядро Linux читал, что у них есть определённый регламент работ. Изменения или проходит или не проходит и всё в таком роде.
F>Идея атомарных коммитов, включающих несколько файлов сразу, появилась давно, еще до гита. Потому что еще раньше были системы контроля версий, работающие с файлами по одиночке, и это было плохо и неудобно.
Уже выше прошло обсуждение на тему систем хранилищ версий предыдущих поколений, но речь в топике не о них. То есть не просто не о них, а вообще не о них. Любые смутные ассоциации в этом направлении неправильны.
Здравствуйте, velkin, Вы писали:
F>>Нет, не файлов. git задуман как система хранения версий исходных кодов программ. И ориентирован в первую очередь на это.
V>Git создал Линус Торвальдс для ядра Linux. Очевидно и работа заточена под это дело. С каким бы проектом у себя не работал, будешь работать как с ядром Linux.
Это уже много лет не так.
V> А про ядро Linux читал, что у них есть определённый регламент работ. Изменения или проходит или не проходит и всё в таком роде.
Это у любой нормальной работы с исходниками (и не обязательно программ).
Например, перетащили текст какого-то юридического параграфа из главы 2 в главу 4. Это одно изменение — перенос.
И не только с исходниками. Ты про транзакции в файловой системе слышал? Windows умеет такое.
F>>Идея атомарных коммитов, включающих несколько файлов сразу, появилась давно, еще до гита. Потому что еще раньше были системы контроля версий, работающие с файлами по одиночке, и это было плохо и неудобно. V>Уже выше прошло обсуждение на тему систем хранилищ версий предыдущих поколений, но речь в топике не о них. То есть не просто не о них, а вообще не о них. Любые смутные ассоциации в этом направлении неправильны.
Тогда зачем вообще привязываться в этой теме к Git?
Здравствуйте, netch80, Вы писали:
V>>Git создал Линус Торвальдс для ядра Linux. Очевидно и работа заточена под это дело. С каким бы проектом у себя не работал, будешь работать как с ядром Linux. N>Это уже много лет не так.
Это не может быть не так, то есть то, что другие люди развивают проект никак не влияет на то откуда взялся git и его основные положения.
N>Это у любой нормальной работы с исходниками (и не обязательно программ). N>Например, перетащили текст какого-то юридического параграфа из главы 2 в главу 4. Это одно изменение — перенос. N>И не только с исходниками. Ты про транзакции в файловой системе слышал? Windows умеет такое.
Есть NTFS, который работает у меня в Debian и Windows. Если имеется в виду вот это Транзакционная NTFS, то нет, я про этот костыль Windows Only первый раз слышу, и он никакого отношения к обсуждению не имеет, как и транзакции. Причём здесь транзакции? Я не знаю.
N>Тогда зачем вообще привязываться в этой теме к Git?
Потому, что эволюция систем хранилища версий файлов и директорий не закончена. Я раньше думал, что же мне не нравится в git, ведь вроде есть децентрализация, а значит автономная работа, слияние и так далее, и вот наконец понял. Git заточен под проекты как абсолютно независимые единицы данных. А чтобы хоть как-то это исправить придумали субмодули и прочее.
Но в итоге получается костыль на костыле и самое главное мало автоматизации, а то и вовсе автоматики. Ведь для чего нужен компьютер и программы, чтобы они выполняли за человека работу. Когда за тебя выполняют работу, то можешь этого не замечать, но когда тебя заставляют выполнять работу, то не заметить это трудно.
Сколько действий нужно предпринять для решения своих задач? Если много, тогда даже в случае успеха система становится неудобной. В идеале это ровно ноль действий со стороны пользователя, это называется автоматикой.
Автома́тика (от греч. αύτόματος — самодействующий) — отрасль науки и техники, которая разрабатывает технические средства и методы для осуществления технологических процессов без непосредственного участия человека.
А если мне всё равно, как оно там сохраняется и синхронизируется пока система хранения версий сама записывает коммиты, то так даже лучше. Или если я хочу взять файл курсором мышки и переместить его в другое хранилище (drag&drop) с сохранением его изменений. А если я хочу хранить файл со всеми его изменениями в разных хранилищах одновременно.
Вот и выходит, что эволюция поколений систем хранения версий ещё не закончена.
Первое поколение
SCCS (Source Code Control System)
RCS (Revision Control System)
Второе поколение
CVS (Concurrent Versions System)
SVN (Apache Subversion)
Третье поколение
Git
Mercurial
Четвёртое поколение???
Ну, это просто тема для обсуждения, это не холивар что-то против чего-то и тому подобное.
Здравствуйте, velkin, Вы писали:
V>Четвёртое поколение??? V>Ну, это просто тема для обсуждения, это не холивар что-то против чего-то и тому подобное.
Непонятно какую проблему ты пытаешься решить.
Так что непонятно что обсуждать. Вот и обсуждаем твоё странное понимание того как работает git. Например, вообще-то git коммитит не файлы, а дерево контента.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
V>Четвёртое поколение???
Если mercurial это третье поколение (как и прочие нашлёпки ко второму поколению типа svk+svn), то git это и будет четвёртое, т.к. он имеет принципиально другое хранилище объектов.
А чтобы пообсуждать что будет в пятом поколении вначале надо сформулировать проблему, решение которой никак не ложится на существующие решения.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Непонятно какую проблему ты пытаешься решить.
Проблема здесь всё та же — управление версиями файлов и директорий. Причём любых файлов и директорий, а не просто программных проектов, хотя даже с ними у git на мой личный взгляд проблемы. По сути git создан для идеальных случаев, а не когда всё погружено в хаос. Чем идеальнее программист организовывает файлы, тем лучше ему будет от использования git. Хотя git не слишком сложен в использовании, но фактически это система управления версиями не для нубов радостно тыкающих кнопки.
А вот когда человек берёт и тыкает что-то в том же проводнике Windows или ещё каком менеджере файлов, вот тогда это система для нубов, хотя версионирования и синхронизации естественно нет. И нуб или новичок это не что-то обидное, напротив система позволяющая легко втянуться нубу и не требующая от него лишних действий по моему мнению превосходит ту, которая что-то постоянно требует. В принципе git можно прокачать создав серию команд для автоматизации рутинных процессов, но как я писал с самого начала принципы работы у него всё же немного другие.
В git вложена идея, что с файлами нужно работать так, а не иначе. Учебники по git говорят, что надо делать так. В gui обычно реализовывают одно и тоже. И поверх всего идея, что файлы в этой директории и поддиректориях часть одного хранилища, за исключением отчасти вредительских субмодулей. А это повод поразмыслить, особенно на фоне шаблонов корпоративных приложений Фаулера, которые по крайне мере в теории гораздо совершеннее существующей системы вроде git.
Здравствуйте, velkin, Вы писали:
V>·>Непонятно какую проблему ты пытаешься решить. V>Проблема здесь всё та же — управление версиями файлов и директорий.
Ты путаешь цель и средство. Управляют версиями файлов не для того, чтобы версии файлов управлялись, шоб было, а для, например, организации процесса разработки программных проектов. Или, например, package manager в линухе управляет версиями файлов чтобы обеспечить установку/обновление/удаление софта.
V>Причём любых файлов и директорий, а не просто программных проектов, хотя даже с ними у git на мой личный взгляд проблемы.
Т.е. хочешь универсальный всемогутер? А оно надо? Я вот не хочу управлять версиями файлов на диске где хранит свои данные какая-нибудь субд и куда я качаю торренты. Ибо накой?!
И вряд ли существуюет универсальный алгоритм, эффективно и удобно поддерживающий, скажем, версирование исходников и обновление софта.
V>По сути git создан для идеальных случаев, а не когда всё погружено в хаос. Чем идеальнее программист организовывает файлы, тем лучше ему будет от использования git. Хотя git не слишком сложен в использовании, но фактически это система управления версиями не для нубов радостно тыкающих кнопки.
Не нужна система в хаосе. Нужна система для борьбы с хаосом.
V>А вот когда человек берёт и тыкает что-то в том же проводнике Windows или ещё каком менеджере файлов, вот тогда это система для нубов, хотя версионирования и синхронизации естественно нет. И нуб или новичок это не что-то обидное, напротив система позволяющая легко втянуться нубу и не требующая от него лишних действий по моему мнению превосходит ту, которая что-то постоянно требует. В принципе git можно прокачать создав серию команд для автоматизации рутинных процессов, но как я писал с самого начала принципы работы у него всё же немного другие.
Менеджер файлов и git это разные вещи, с разными целями.
V>В git вложена идея, что с файлами нужно работать так, а не иначе. Учебники по git говорят, что надо делать так. В gui обычно реализовывают одно и тоже. И поверх всего идея, что файлы в этой директории и поддиректориях часть одного хранилища, за исключением отчасти вредительских субмодулей. А это повод поразмыслить, особенно на фоне шаблонов корпоративных приложений Фаулера, которые по крайне мере в теории гораздо совершеннее существующей системы вроде git.
Что за такие шаблоны?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, velkin, Вы писали:
V>Как известно git немного извращённая система хранения версий файлов, но не директорий, последних попросту нет. Размышлял про синхронизацию файлов и мне в голову пришла мысль, что git то ведь ставит коммит на файлы, а не файл.
Это принципиальная позиция Линуса: https://gist.github.com/dukeofgaming/2150263
The problem of thinking in terms of single files is that quite often, especially if you are high-level maintainer like me, I have 22,000 files to track, I do not care about one of them. I might care about a subcollection of them that contains maybe 1,000 files, I might care about the USB subsystem. But I never care about a single file. So git tracks everything as a collection of files, and if you ask for the history of a single file, git will literally start from the global history and it simplifies it. It is a very efficient system, you would normally not even realize that it does that, but it does mean that if you try to track a million files in one repository, when you then ask for a single-file history, it's going to be slower. So it has a different scaling properties than a lot of other systems for this very fundamental design reason. We have used big repositories. We've imported things like the whole SVN history of, maybe not the whole -- something like 3/4 of the SVN history of the whole KDE project. And the KDE people are, eh ... I shouldn't call them, ... I won't, I like KDE, but trust me. But they put every single component in one repository. Not very smart.
Здравствуйте, velkin, Вы писали:
V>А это повод поразмыслить, особенно на фоне шаблонов корпоративных приложений Фаулера, которые по крайне мере в теории гораздо совершеннее существующей системы вроде git.
Фаулера обычно надо читать очень внимательно, это крайне полезные книги. А потом всё делать полностью наоборот.
Здравствуйте, velkin, Вы писали:
V>Вопрос отчасти философский, но что если бы изначально был заложен принцип изменения каждого файла в отдельности. Ведь тогда бы и программисты смотрели на деревья изменения каждого файла в отдельности, а не на одно дерево изменения файлов.
Потому, что программистам не нужно отслеживать изменение каждого файла в отдельности.
Вот, допустим, у меня есть программа, состоящая из трех файлов, main.c, foo.c, foo.h:
И допустим теперь, в результате рефакторинга, программист решил переименовать функцию foo() в функцию bar(). Это изменение затронет три файла, а не один, но логически это единое изменение. Никому не нужны промежуточнуе версии программы, в которых изменена только часть этих файлов, эти промежуточные версии просто не соберутся.
Поэтому в системе управления версиями кода очень удобно иметь атомарные комиты, которые описывают изменение группы файлов, как единое действие.
V>Собственно откуда такая мысль. Для проекта могут быть важны теги завершённости программы и всё в таком роде. Но как никто не мешает делать коммиты под изменения каждого файла, так никто не мешает выстроить изменения файлов в единую цепочку и привязывать тег к изменению последнего файла.
Если это у системы под капотом, то это ее личное дело, хотя вряд ли будет наиболее эффективно с точки зрения именно реализации. А если такое торчит в пользовательский интерфейс, оно будет только мешаться.
V>Фактически многим было бы достаточно просто одной кнопки "сохранить в хранилище" и всё, а если так уж нужен коммит, то просто автоматически ставить номер текущего изменения, который каждый раз будет увеличиваться на один.
Нет. Границы коммита и коментарий к нему — это метаинформация "вот этот набор изменений — единое действие с таким-то смыслом". Автоматически этого сделать нельзя, автомат не знает, где границы логически единых действий, и с какой целью эти действия были произведены,
V>Вот и выходит, инструмент есть, он работает, но провоцирует работу с собой именно так, а не иначе. Соответственно все механизмы заточены на другой стиль работы, если не пожертвовать удобством или дописать свой инструмент над этим.
Да. Для других стилей работы есть другие инструменты, или их кто-со создаст, когда появится ясное понимание их необходимости.
V>Да и в принципе это размышления про синхронизацию файлов. Можно ли сказать, что уровень удобства с системами хранения версий достиг максимума. Лично я такого сказать не могу.
Здравствуйте, ·, Вы писали:
·>Если mercurial это третье поколение (как и прочие нашлёпки ко второму поколению типа svk+svn), то git это и будет четвёртое, т.к. он имеет принципиально другое хранилище объектов.
Mercurial совершенно изоморфен git'у. Что у него там данные под капотом немного в другом виде хранятся, это его личное дело.
·>А чтобы пообсуждать что будет в пятом поколении вначале надо сформулировать проблему, решение которой никак не ложится на существующие решения.
Хорошо бы, если бы оно понимало смысл того, что версионирует. Тогда, к примеру, если у нас есть строка с арифметическим выражением, и один комит меняет имя переменной, не меняя смысла, а другой меняет выражение, пользуясь при этом старой версией имени переменной, то эти два комита в этой строке автоматически бы сливались, а не так, как сейчас.
Здравствуйте, Pzz, Вы писали:
Pzz>·>Если mercurial это третье поколение (как и прочие нашлёпки ко второму поколению типа svk+svn), то git это и будет четвёртое, т.к. он имеет принципиально другое хранилище объектов. Pzz>Mercurial совершенно изоморфен git'у. Что у него там данные под капотом немного в другом виде хранятся, это его личное дело.
Не личное. Некоторые операции манипулирования историей и управлением ветками в таком хранилище становятся неэффективными и практически неюзабельными.
Pzz>·>А чтобы пообсуждать что будет в пятом поколении вначале надо сформулировать проблему, решение которой никак не ложится на существующие решения. Pzz>Хорошо бы, если бы оно понимало смысл того, что версионирует. Тогда, к примеру, если у нас есть строка с арифметическим выражением, и один комит меняет имя переменной, не меняя смысла, а другой меняет выражение, пользуясь при этом старой версией имени переменной, то эти два комита в этой строке автоматически бы сливались, а не так, как сейчас.
Это не функция скв как таковой, а алгоритмов слияния конфликтов. git сам по себе хранит по сути полный снапшот каждого закоммиченного состояния и по умолчанию зовёт встроенные дефолтные тулзы типа diff/patch. Ты можешь на разные типы файлов назначить свои тулзы и парсь/диффь/сливай арифметические выражения как душе угодно.
Pzz>Но вряд ли мы этого дождемся.
Не в этой Вселенной. Потому что это в общем случае алгоритмически неразрешимая задача.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
Pzz>>Mercurial совершенно изоморфен git'у. Что у него там данные под капотом немного в другом виде хранятся, это его личное дело. ·>Не личное. Некоторые операции манипулирования историей и управлением ветками в таком хранилище становятся неэффективными и практически неюзабельными.
Например?
·>Это не функция скв как таковой, а алгоритмов слияния конфликтов. git сам по себе хранит по сути полный снапшот каждого закоммиченного состояния и по умолчанию зовёт встроенные дефолтные тулзы типа diff/patch. Ты можешь на разные типы файлов назначить свои тулзы и парсь/диффь/сливай арифметические выражения как душе угодно.
Мне бы хотелось готовый инструмент, а не набор запчастей для сборки своего.
Pzz>>Но вряд ли мы этого дождемся. ·>Не в этой Вселенной. Потому что это в общем случае алгоритмически неразрешимая задача.
Многие алгоритмически неразрешимые задачи имеют практически полезное решения, заключающееся в том, что алгоритм делает все, что может, а в остальных случаях обращается за помощью к человеку.
