Итак, я учился ртути.
Был один момент, когда в учебнике [ссылка] автор говорил о создании второго репозитория в качестве репозитория разработчика помимо стабильного репозитория. Как видно из названия, он планировал использовать это для разработки и продвигать стабильные версии после пометки их.
Интересно, почему? Когда мы можем просто создать ветку, зачем вообще второе репо?
Меня поразили две неотложные проблемы:
- Это займет больше места, поскольку мы продолжаем клонировать одни и те же данные снова и снова.
- Как это соотносится с ветвлением, в ветвлении у нас все версии находятся в одном месте, по крайней мере, это то, что я видел в репозиториях многих организаций на GitHub, таких как OpenCV
Пока я не нашел ответа на второй вопрос, ответ на первый довольно интересен.
Mercurial использует жесткие ссылки
Допустим, у нас есть репо под названием `project-stable-1.0`, теперь для разработки следующей версии мы просто клонируем его, говоря` project-dev-2.0`.
Теперь происходит то, что проект `project-dev-2.0` имеет всю информацию как project-stable-1.0 все файлы, все, но ... но ... информация НЕ копируется.
Вот что такое жесткие ссылки.
Таким образом, в основном файлы могут иметь несколько имен, что противоречит прежней интуиции, но да, несколько имен одного и того же файла.
Таким образом, исполняемый файл python хранится на жестком диске в каком-то блоке, он может иметь несколько имен в разных местах, но информация хранится только в одном месте:
Оба
Программные ссылки или символические ссылки - это ссылки между файлами:
Давайте немного поэкспериментируем и посмотрим!
В настоящее время мы находимся в каталоге внутри `/home/Documents/blog/`
В Linux команда «ln» по умолчанию создает жесткую ссылку. Давайте создадим его для a.cpp.
`$ ln a.cpp hardlink_to_a`
Итак, у нас есть новый файл!
Теперь давайте создадим мягкую ссылку на a.cpp. | Просто передайте флаг -s команде `ln`
`$ ln -s a.cpp softlink_to_a`
Вы видите этот красивый цвет и стрелку в последней строке, также обратите внимание на l в lrwxrwxrwx в последней строке, которое показывает, что symlink там !
Но, к сожалению, нет ничего, что показало бы, что a.cpp и hardlink_to_a связаны 😕
Пора надеть шляпу Шерлока 🔬 😎 [без наклеек]
Команда stat на a.cpp и hardlink_to_a что-то обнаруживает!
Обратите внимание на номера inode a.cpp и hardlink_to_a, они одинаковые !! Он даже показывает 2 в записи "Ссылки"! В то время как softlink_to_a имеет другой индексный дескриптор.
Что такое i-узлы? 👀
Inodes - это индексы. Каждый файл имеет структуру данных (запись) в файловой системе, известную как индексный дескриптор, в котором хранится информация о файле. По сути, это первичный ключ в базе данных.
В этом случае наличие одинаковых номеров inode означает, что они являются одной и той же записью в базе данных файловой системы и имеют разные имена.
Итак, в софт-ссылке есть еще один индексный дескриптор, который указывает на этот индекс:
Жесткие ссылки бывают разные:
Как вы можете видеть, как «имена» указывают на один и тот же индексный дескриптор, а индексные дескрипторы - это запись в файловой системе, вы не можете создать жесткую ссылку за пределами определенной файловой системы, потому что это содержимое не будет существовать в другая файловая система.
Поведение при изменении источника
Когда вы перемещаете или удаляете источник этих ссылок, они ведут себя иначе! Символические ссылки просто содержат строку, которая представляет собой путь к цели, поэтому она не обновляется, поэтому символическая ссылка сейчас не используется. С другой стороны, жесткие ссылки всегда относятся к источнику, даже если они перемещены или удалены. Так что никакого эффекта на это 😎
Например, если мы удалим a.cpp. softlink_to_a относится к нулевому файлу ‘a.cpp’, который больше не существует, но новое имя файла a.cpp будет создано, если вы отредактируете te softlink_to_a. Но жесткая ссылка не повреждена!
Но мы все еще можем использовать hardlink_to_a | $ nano hardlink_to_a
Недостаток жестких ссылок
В вашей установке linux может быть несколько файловых систем, но наиболее существенным недостатком является то, что невозможно создать жесткие ссылки для связывания файла из одной файловой системы с другим файлом в другой файловой системе. Каждая файловая система хранит свою собственную информацию о внутренней структуре системы и отдельных файлах в системе. Жесткие ссылки знают только эту системную информацию, поэтому жесткие ссылки не могут охватывать файловые системы. Мягкие ссылки, с другой стороны, знают имя файла, просто строку, которая является более общей, и, таким образом, могут охватывать файловые системы. [1]
В качестве конкретной аналогии предположим, что наш друг Саян Синха учится в IIT-KGP и Стэнфордском университете. Оба университета присваивают ему номер в списке. Если он попытается использовать свой номер студента IIT-KGP в Стэнфорде, он не добьется успеха. Он также потерпит неудачу, если попытается использовать свой номер студента Стэнфорда в IIT. Но если он использует свое официальное имя, Саян Синха, он, вероятно, добьется успеха 🎉. Номера списков зависят от университета (например, жесткие ссылки), в то время как его официальное имя охватывает оба университета (например, программные ссылки). [1]
Вот пример, демонстрирующий ситуацию, когда жесткая ссылка не может использоваться и требуется символическая ссылка. Предположим, мы пытаемся создать жесткую ссылку из текущего рабочего каталога на a.cpp
Пример, демонстрирующий это:
Команда ln не работает, потому что файл .cpp хранится в другой файловой системе. Если мы хотим создать на него ссылку, нам нужно будет использовать символическую ссылку:
Различия:
Символические ссылки:
- Легко понять: особенно если вы уже использовали окна раньше
- Работает как для файлов, так и для каталогов
- Работает с файловыми системами
Жесткие ссылки:
- Трудно узнать
- Работает только для файлов
- Невозможно в файловых системах
- Лучшая производительность
Таким образом, использование жесткой ссылки в hg clone делает операцию быстрой и дешевой.
Источники:
