Посмотрел известное выступление Торвальдса в гугле по поводу git, практически все понятно, но одна деталь не дает мне покоя. Торвальдс говорит ближе к концу о том, что git, в отличие от других систем контроля версий, отслеживает историю проекта "целиком", а не пофайлово. Мне интересно — Торвальдс считает это именно особенностью DCVS-подхода в сравнении с SVN либо же git как-то совсем по-другому манипулирует версионируемым контентом, даже не так, как это делает меркуриал ? Если первый вариант и Линус этим предложением сравнивает git и svn, то все понятно — git манипулирует деревом коммитов, а svn — деревом файлов. Однако если вариант второй, то в чем же может быть различие в подходе между git и mercurial ? По-моему, между ними различия в основном непринципиальные (типа что у гита нет named branches, а у меркуриала нельзя сливать за раз больше 2 ветвей).
В общем, хотелось бы уточнить, что Линус имеет в виду, и как его система трекает историю функций между файлами (ведь из контекста выступления кажется, что только гит это умеет делать — вопрос — можно ли сделать аналогичную функциональность скажем в mercurial, или это невозможно в силу дизайна).
Здравствуйте, elw00d, Вы писали:
E>Посмотрел известное выступление Торвальдса в гугле по поводу git, практически все понятно, но одна деталь не дает мне покоя. Торвальдс говорит ближе к концу о том, что git, в отличие от других систем контроля версий, отслеживает историю проекта "целиком", а не пофайлово. Мне интересно — Торвальдс считает это именно особенностью DCVS-подхода в сравнении с SVN либо же git как-то совсем по-другому манипулирует версионируемым контентом, даже не так, как это делает меркуриал ? Если первый вариант и Линус этим предложением сравнивает git и svn, то все понятно — git манипулирует деревом коммитов, а svn — деревом файлов.
Нет. SVN тоже не работает как таковое с деревом файлов, это не CVS. SVN сходно с git методами работы с контентом — действия определяются сразу по группе объектов, обычно иерархически собранных, как файлы.
Отличие тут только то, что формально на нижнем уровне git это не файлы, а просто как-то именованные объекты (строками, завершёнными нулевым символом), и на нижнем уровне можно с ними работать не как с файлами. Но, на моей памяти, никто так с этими объектами не работает. Хотя, может, я не знаю про какие-то особенности. Для юзера, работающего с файловым деревом, это всё пофиг.
Более того, рассказы, например, что в git единицей хранения является порция содержания, неверны. Например, перемещение файла — это удаление одной копии и создание другой, а логическое оформление действия как перемещение производится уже уровнем выше (когда ищется similarity index и если он 100%, то это просто перемещение).
E> Однако если вариант второй, то в чем же может быть различие в подходе между git и mercurial ? По-моему, между ними различия в основном непринципиальные (типа что у гита нет named branches, а у меркуриала нельзя сливать за раз больше 2 ветвей). E>В общем, хотелось бы уточнить, что Линус имеет в виду, и как его система трекает историю функций между файлами (ведь из контекста выступления кажется, что только гит это умеет делать — вопрос — можно ли сделать аналогичную функциональность скажем в mercurial, или это невозможно в силу дизайна).
git может следить историю между файлами, но, как уже сказал, делает это хреново. Чтобы найти факт перемещения функции, например, надо дойти до коммита, где эта функция перешла в другой файл и перезапустить чтение истории уже для этого файла. Это возможно, но как минимум на уровне CLI неудобно. Может, какой-то GUI есть, что это следит, я не видел.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, elw00d, Вы писали:
E>>Посмотрел известное выступление Торвальдса в гугле по поводу git, практически все понятно, но одна деталь не дает мне покоя. Торвальдс говорит ближе к концу о том, что git, в отличие от других систем контроля версий, отслеживает историю проекта "целиком", а не пофайлово. Мне интересно — Торвальдс считает это именно особенностью DCVS-подхода в сравнении с SVN либо же git как-то совсем по-другому манипулирует версионируемым контентом, даже не так, как это делает меркуриал ? Если первый вариант и Линус этим предложением сравнивает git и svn, то все понятно — git манипулирует деревом коммитов, а svn — деревом файлов.
N>Нет. SVN тоже не работает как таковое с деревом файлов, это не CVS. SVN сходно с git методами работы с контентом — действия определяются сразу по группе объектов, обычно иерархически собранных, как файлы. N>Отличие тут только то, что формально на нижнем уровне git это не файлы, а просто как-то именованные объекты (строками, завершёнными нулевым символом), и на нижнем уровне можно с ними работать не как с файлами. Но, на моей памяти, никто так с этими объектами не работает. Хотя, может, я не знаю про какие-то особенности. Для юзера, работающего с файловым деревом, это всё пофиг.
N>Более того, рассказы, например, что в git единицей хранения является порция содержания, неверны. Например, перемещение файла — это удаление одной копии и создание другой, а логическое оформление действия как перемещение производится уже уровнем выше (когда ищется similarity index и если он 100%, то это просто перемещение).
E>> Однако если вариант второй, то в чем же может быть различие в подходе между git и mercurial ? По-моему, между ними различия в основном непринципиальные (типа что у гита нет named branches, а у меркуриала нельзя сливать за раз больше 2 ветвей). E>>В общем, хотелось бы уточнить, что Линус имеет в виду, и как его система трекает историю функций между файлами (ведь из контекста выступления кажется, что только гит это умеет делать — вопрос — можно ли сделать аналогичную функциональность скажем в mercurial, или это невозможно в силу дизайна).
N>git может следить историю между файлами, но, как уже сказал, делает это хреново. Чтобы найти факт перемещения функции, например, надо дойти до коммита, где эта функция перешла в другой файл и перезапустить чтение истории уже для этого файла. Это возможно, но как минимум на уровне CLI неудобно. Может, какой-то GUI есть, что это следит, я не видел.
Что-то я совсем теперь запутался. Насчет SVN и git мне кажется, что все верно — хоть вы и написали, что SVN работает не как CVS. Вы имели в виду то, что коммит атомарен в svn как и в git ? Но git идет дальше и в его истории мы видим дерево коммитов (ациклический граф, точнее), а в svn — только прямую историю. И ветки svn всегда идут "параллельно" (потому что merge на самом деле не merge, а получение диффа и потом его применение на текущей ветке). Поэтому Линус говорит о том, что "контент" проекта виден в git целиком, а в svn мы видим только историю текущей ветки с непонятными вкраплениями патчей из других веток. Поправьте, если я неправильно понимаю.
Здравствуйте, elw00d, Вы писали:
E>Что-то я совсем теперь запутался. Насчет SVN и git мне кажется, что все верно — хоть вы и написали, что SVN работает не как CVS. Вы имели в виду то, что коммит атомарен в svn как и в git ?
Дело не только в этом. В SVN и git вообще нет хранения именно файлов. Это хорошо можно понять на следующем примере: в CVS в принципе нельзя сделать, чтобы один и тот же путь был и файлом, и каталогом, в разных ветках, или в разные времена жизни одной ветки.
E> Но git идет дальше и в его истории мы видим дерево коммитов (ациклический граф, точнее), а в svn — только прямую историю. И ветки svn всегда идут "параллельно" (потому что merge на самом деле не merge, а получение диффа и потом его применение на текущей ветке). Поэтому Линус говорит о том, что "контент" проекта виден в git целиком, а в svn мы видим только историю текущей ветки с непонятными вкраплениями патчей из других веток.
Мне в общем-то нет дела до того, что говорит именно Линус — потому что то, что он говорит, надо делить на 2. То, что видно в git, действительно показывает историю развития более сложно, чем один прямолинейный путь. Но это к истории собственно файла с перемещением его содержимого имеет мало отношения — Вы тут уже начинаете смешивать совершенно разные вещи в один флакон. Давайте их всё-таки разделять.
В SVN мы видим текущую ветку (точнее, текущую историю в пределах репо — из-за специфического подхода SVN там ветки представляются как каталоги в общем репо). Но никто не мешает — по крайней мере в пределах одного репо — обозначать слияния так, чтобы их можно было проследить; этим просто никто не занимался систематизированно, AFAIK. Поэтому, видя commit message, что было слияние, дальше его историю можно следить только вручную. И только в одном репо. Для некоторых это принципиальное ограничение, но это именно различие CVCS vs. DCVS. Для Linux централизованная система не годилась (по крайней мере по мнению ведущих), поэтому они не стали использовать ни CVS, ни SVN.
E> Поправьте, если я неправильно понимаю.
Просто не смешивайте разные вещи. VCS (SCM, как кому нравится называть) — очень многоаспектные продукты, и надо чётко различать, о чём именно идёт речь в каком случае.
