Так я этого и не утверждал, с чем вы с таким упорством спорите?
А если не утверждаете, то зачем использовать эти аналогии к git и вообще к системах управления версиями. Как сделано в файловых системах и правильно или нет, не имеет никакое отношение к вопросу как правильно делать в системах управления версиями. Именно это я пытаюсь объяснить.
Ну а что, раз worktree это костыль потому что в Fossil она не нужна, значит и open тоже костыль, потому что в Git он не нужен.
Ну да, open определено костыль. Я даже и не знаю почему его ввели. К тому же, есть комманда close, но она практически используется только когда хочешь удалить рабочую директорию и только чтобы проверить нет ли не записанные изменения. А так, директорию можно просто удалить и с репозитория ничего не будет.
Я говорил что репозиторий аналог файла, лишь для упрощения. Конечно, все существующие системы управляют группы файлов, но это не меняет суть что в репозиторий отличается от checkout-а лишь наличием времени как измерение. А checkout, он имеет та же сущность как и репозиторий, только на измерение меньше. И поэтому все чекауты, равноправные и работа с них должна быть одинаковой, через одни и те же команды и опции. Это всегда увеличивает интуитивность интерфейса и соответствует правилу наименьшего удивления
Ничего не мешает файлу иметь несколько hardlink'ов одновременно и все они будут совершенно равноправными.
Ну и что? Как я уже говорил, хард линки не являются аналогией рабочих директориях и поэтому как это у них сделано и правильно ли оно или нет, совершенно ортогонально к обсуждаемым вопросом.
Конечно. Файловая система всего лишь БД. В SQL БД например файловые имена вообще нет.
Но какое отношение это имеет к git?
Если идеология git строилась как супер-аналогия файловой системы, где репозиторий это файл, а рабочая директория, это имя файла, то как я и говорил, это ошибочная аналогия. И эсли репозиторий можно считать за файла, у которого еще одно измерение – время, то рабочая директория совершенно не является имя этого файла. Она является просто срез, образец файла в некотором моменте времени. То есть рабочая директория то же самое что и репозиторий, только у нее на одно измерение меньше. Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.
Пример неудачный. Жесткая ссылка (имя файла) обязательный атрибут файла.
Файлы с нулевым количеством ссылок перестают существовать для системы и, со временем, будут перезаписаны физически.
А вот, репозиторий с нулевым количеством рабочих директории вполне возможен и у меня встречается сплошь и рядом, например временно приостановленные проекты или мастер репозитории на сервере.
Исторически в git принято держать рабочую директорию и данные в одном каталоге.
Плохое решение, которое пришлось исправлять через лишние конструкции. Изначально симметричная ситуация (все рабочие директории равноправные), пришлось делать несимметричной – главная и дополнительные.
А как же? Чем различаются головная рабочая директория и эти вторичные? А ничем не отличаются. А почему, однa появляется как бы сама по себе, а другие надо через тайную команду "worktree"? А потому что костыль из за обратной совместимости.
Безусловно, недостаток. Лишний расход памяти и машинного времени всегда недостаток и большой.
И кстати, создатели git наверное тоже так считают, потому что сделали "worktree" (а ведь когда писалась обсуждаемая статья, эту команду не было). Правда worktree все таки костыль, но сделали же. :)
Принципиальной разницы нет, только Fossil более многословный.
Может быть, но просто посмотрите на команды. У fossil все команды совершенно ясные и прямолинейные. Там вопросы не возникают, даже у человека незнакомого с fossil. Точно можно сказать зачем та или иная команда пишется и что она делает.
А в git это не так. Человек должен знать что есть такую команду как worktree, а откуда он может узнать если рабочая директория создается автоматически. Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.
А переключаться между ветками обычно все-таки удобнее через checkout, а не через создание новой рабочей копии.
В fossil команда checkout (синонимы: checko, check, chec, che, co) тоже имеется и используется широко. Только я привык работать одновременно над нескольких задачах в рамках проекта и тогда гораздо более удобно иметь раздельные директории. Вообще я новые ветки создаю постоянно. Примерно 10 активные ветки не предел.
Workflow может быть каким угодно, а опции используются только когда надо ломать обычный порядок. По моему так и должно быть. А ведь git (и все другие) тоже продвигает "правильный" workflow:
Просто запомни эти команды шелла. Вводи их, когда нужно синхронизироваться. Если выскочит ошибка, сохрани где-нибудь свою работу, удали проект и скачай свежую копию.
open не checkout. fossil open REPO VERSION означает: Хочу чтобы здесь была рабочая директория проекта "REPO" и чтобы восстановилась из репозитория версия VERSION.
Потом, версию (checkin) можно менять через fossil co VERSION или синоним fossil update VERSION.
А VERSION может быть код версии, имя ветки, присвоенный tag и т.д.
P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное. Например переключить на другую версию, но не восстанавливать файлы из репозитория.
Вот именно! И это им не нравится совершенно. И будут делать все, чтобы их не заставляли. М$ всегда работала так и никак иначе.
Это они так говорят?
Embrace, extend, and extinguish
Это конечно так, только инструменты тоже надо быть безопасными. Если наступы на лопате не отогнуты, учи не учи, а ботинки все равно порвешь.
А класика
(#ffffff и/или #ffff00) на #000080это светлая или темная?А если не утверждаете, то зачем использовать эти аналогии к git и вообще к системах управления версиями. Как сделано в файловых системах и правильно или нет, не имеет никакое отношение к вопросу как правильно делать в системах управления версиями. Именно это я пытаюсь объяснить.
Ну да, open определено костыль. Я даже и не знаю почему его ввели. К тому же, есть комманда close, но она практически используется только когда хочешь удалить рабочую директорию и только чтобы проверить нет ли не записанные изменения. А так, директорию можно просто удалить и с репозитория ничего не будет.
Я говорил что репозиторий аналог файла, лишь для упрощения. Конечно, все существующие системы управляют группы файлов, но это не меняет суть что в репозиторий отличается от checkout-а лишь наличием времени как измерение. А checkout, он имеет та же сущность как и репозиторий, только на измерение меньше. И поэтому все чекауты, равноправные и работа с них должна быть одинаковой, через одни и те же команды и опции. Это всегда увеличивает интуитивность интерфейса и соответствует правилу наименьшего удивления
Ну и что? Как я уже говорил, хард линки не являются аналогией рабочих директориях и поэтому как это у них сделано и правильно ли оно или нет, совершенно ортогонально к обсуждаемым вопросом.
Конечно. Файловая система всего лишь БД. В SQL БД например файловые имена вообще нет.
Но какое отношение это имеет к git?
Если идеология git строилась как супер-аналогия файловой системы, где репозиторий это файл, а рабочая директория, это имя файла, то как я и говорил, это ошибочная аналогия. И эсли репозиторий можно считать за файла, у которого еще одно измерение – время, то рабочая директория совершенно не является имя этого файла. Она является просто срез, образец файла в некотором моменте времени. То есть рабочая директория то же самое что и репозиторий, только у нее на одно измерение меньше. Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.
Пример неудачный. Жесткая ссылка (имя файла) обязательный атрибут файла.
А вот, репозиторий с нулевым количеством рабочих директории вполне возможен и у меня встречается сплошь и рядом, например временно приостановленные проекты или мастер репозитории на сервере.
Не понял. Это в git что ли?
Плохое решение, которое пришлось исправлять через лишние конструкции. Изначально симметричная ситуация (все рабочие директории равноправные), пришлось делать несимметричной – главная и дополнительные.
А как же? Чем различаются головная рабочая директория и эти вторичные? А ничем не отличаются. А почему, однa появляется как бы сама по себе, а другие надо через тайную команду "worktree"? А потому что костыль из за обратной совместимости.
Безусловно, недостаток. Лишний расход памяти и машинного времени всегда недостаток и большой.
И кстати, создатели git наверное тоже так считают, потому что сделали "worktree" (а ведь когда писалась обсуждаемая статья, эту команду не было). Правда worktree все таки костыль, но сделали же. :)
Может быть, но просто посмотрите на команды. У fossil все команды совершенно ясные и прямолинейные. Там вопросы не возникают, даже у человека незнакомого с fossil. Точно можно сказать зачем та или иная команда пишется и что она делает.
А в git это не так. Человек должен знать что есть такую команду как worktree, а откуда он может узнать если рабочая директория создается автоматически. Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.
Ведь все о чем автор написал надо куда нибудь впихнуть, а корпус и платы не резиновые.
В fossil команда checkout (синонимы: checko, check, chec, che, co) тоже имеется и используется широко. Только я привык работать одновременно над нескольких задачах в рамках проекта и тогда гораздо более удобно иметь раздельные директории. Вообще я новые ветки создаю постоянно. Примерно 10 активные ветки не предел.
Workflow может быть каким угодно, а опции используются только когда надо ломать обычный порядок. По моему так и должно быть. А ведь git (и все другие) тоже продвигает "правильный" workflow:
:-D
open не checkout.
fossil open REPO VERSIONозначает: Хочу чтобы здесь была рабочая директория проекта "REPO" и чтобы восстановилась из репозитория версия VERSION.Потом, версию (checkin) можно менять через
fossil co VERSIONили синонимfossil update VERSION.А VERSION может быть код версии, имя ветки, присвоенный tag и т.д.
P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное. Например переключить на другую версию, но не восстанавливать файлы из репозитория.