Меркуриал
Одной вещи в меркуриале я в принципе понять не могу.
Я меняю файл А, делаю commit и push, потом я меняю дома файл Б и делаю commit, а на попытку push меня посылаютфпень делать pull/merge/commit.
Вопрос - почему бы независимые изменения в разных папках не мержить автоматом, как это сделано в svn?
PS: А теперь рассмотрим, как это положено делать:
1) дерево исходников представляет собой граф, узлы которого - каталоги и блобы с файлами, а связи - связь между каталогом и расположенными в нем подкаталогами и файлами.
2) пользователь 1 меняет файл с путем A
3) пользователь 2 меняет другой файл с путем B.
4) Друг другу они в принципе никак не мешают - структура графа не меняется, меняются два независимых узла.
5) операции коммутируют - т.е. вне зависимости от порядка применения операций, результат будет одним и тем же.
6) для коммутирующих операций merge должен делаться, очевидно, автоматически.
Я меняю файл А, делаю commit и push, потом я меняю дома файл Б и делаю commit, а на попытку push меня посылают
Вопрос - почему бы независимые изменения в разных папках не мержить автоматом, как это сделано в svn?
PS: А теперь рассмотрим, как это положено делать:
1) дерево исходников представляет собой граф, узлы которого - каталоги и блобы с файлами, а связи - связь между каталогом и расположенными в нем подкаталогами и файлами.
2) пользователь 1 меняет файл с путем A
3) пользователь 2 меняет другой файл с путем B.
4) Друг другу они в принципе никак не мешают - структура графа не меняется, меняются два независимых узла.
5) операции коммутируют - т.е. вне зависимости от порядка применения операций, результат будет одним и тем же.
6) для коммутирующих операций merge должен делаться, очевидно, автоматически.
no subject
Ты упускаешь важную часть графа. Про mercurial не скажу, в git оно выглядит так: есть четыре вида объектов: blob, tree, commit, tag. Все объекты адресуются по содержимому -- хэш от содержимого.
Что содежит blob понятно. tree -- список ссылок на blob'ы и другие деревья. Таким образом строится иерархия. commit -- ссылка на корневое дерево проекта, commit message + нуль или более ссылок на parent commit (больше 1 для merge commit). tag -- ссылка любой объект, чаще всего commit.
Из вышесказанного очевидно, что изменение одного blob'а повлечёт к изменению всех объектов выше по стеку: blob -> tree -> commit -> tag.
Т.е. операции не коммутирующие. И это сделано намеряно. Для distributed scm критически важно лёгкое отслеживание целостности, дабы избежать code injection и прочие проблемы с безопастностью.
no subject
4/5 - ломает, ломает порядок коммитов: будет ломать ребейс. Будет появляться лишний merge сщььше на C которого нет ни на A ни на B
no subject