Здравствуйте, MaxLovic, Вы писали:
ML>Добрый день.
ML>Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети. ML>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах. ML>Попробовал mercurial, немного удобнее под виндой, но функционал тот же.
ML>Сейчас единственным вариантом вижу залить свой svn репозиторий (папку на жестком диске) в гит репозиторий и периодически делать commit и pull. Но решение какое-то кривое. ML>Может есть какие еще VCS для моих задач? Или может я не полностью разобрался с git и с его помощью можно организовать такой же рабочий процесс?
Конечно есть. Это bzr.
Начнем с того, что он умеет работать с твоим svn-репозиторием, как со своим собственным, из коробки, без каких-либо плагинов. То есть, во всех командах bzr ты можешь указывать в качестве бранча путь к своему svn-репозиторию, и все будет прекрасно работать.
То есть, ты можешь как конвертировать все в базаровские бранчи однократно, так и продолжить использовать свой svn-репозиторий, выполняя с ним push и pull из бранчей bzr.
Во-вторых, в отличии от git и bzr, его команды работают на уровне отдельных бранчей, а не репозитория целиком — ровно как тебе хочется (и не одному тебе). В сети полно материала на эту тему, в т.ч. на русском.
В третьих, к нему есть прекрасный гуй, который прекрасно работает под вендой. Как знакомый тебе Tortoise, так и QBzr, который позволяет работать с командной строкой, не запоминая при этом сотни флагов.
Здравствуйте, ., Вы писали:
A>>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей. .>А в каких нет? git тоже умеет,
Ага. А когда я второй бранч того же проекта таким образом захочу "склонировать" — он ляжет в другой репозиторий, и у меня еще разок полностью прокачается его полная история. Удобно.
.>умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет).
В bzr понятия бранча, репозитория, и рабочей копии полностью независимы, и ими очень просто манипулировать раздельно. В отличии от.
Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>У svn, единицей фетча является одна ревизия одного каталога, в распределённых обязательно нужно клонировать все каталоги, что создаёт трудности при переезде массивного svn репозитория в распределённую систему контроля.
Могу произвольным образом SVN-репозиторий на бранчи нарезать, и разложить эти бранчи по репозиториям так же произвольно — как мне захочется. После чего — легко и непринужденно между репозиториями их перекидывать, и push-ить результаты из любого места обратно в SVN. Все это стандартными командами, отличие только в том что иногда url-е будет указывать в SVN.
А как там в ваших гитах — не знаю. Помню, что как-то сильно сложно.
Здравствуйте, ., Вы писали:
.>Здравствуйте, Gaperton, Вы писали:
A>>>>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>>>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей. .>>>А в каких нет? git тоже умеет, G>>Ага. А когда я второй бранч того же проекта таким образом захочу "склонировать" — он ляжет в другой репозиторий, и у меня еще разок полностью прокачается его полная история. Удобно. .>Зачем? Закачай бранч в тот же репо, скачаются только отсутствующие коммиты.
Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит.
В bzr все просто до скуки.
Один раз делаешь вот это:
D:
cd \
bzr init-repo
После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить.
Что мне надо знать, чтобы добиться аналогичного в git?
.>>>умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет). G>>В bzr понятия бранча, репозитория, и рабочей копии полностью независимы, и ими очень просто манипулировать раздельно. В отличии от. .>Тоже есть shared repository. Рабочая копия, репозиторий и индекс тоже можно разделить. Только непонятно зачем — клоны могут использовать хардлинки для легковесности.
G>>bzr chechout --lightweight branch_path working_copy_path .>git clone -b branchName git_repo_on_same_filesystem
Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.
.>Правда не представляю накой такое нужно.
Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или...
...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна?
Кстати, а что будет с хардлинками под вендой?
.>Обычно бранчи переключать приходится в одном и том же месте, т.к. всё окружение настроено туда.
bzr switch, если что . А то некоторые думают, что bzr этого не умеет.
G>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча". .>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.
Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?
А вот checkout --lightweight всегда работает, во всех контекстах.
Здравствуйте, ., Вы писали:
G>>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно. .>Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее.
Это у вас в гите все кругом дело привычки. А в bzr можно выбирать между обоими способами по ситуации.
G>>Данная фича полезна для быстрого вынимания из репозитория конкретной ревизии по нужде, с целью, например, воспроизведения ошибки, проявляющейся в конкретной версии. Создать рабочую копию, вынув из репа исходники — это естественно и понятно. Клонировать в этой ситуации репозиторий, потому что это "быстро работает" — контринтуитивно как-то. .>А если вперёд-назад по коммитам походить захочешь, что-то поменять там чуть, а потом помержить туда-сюда?
Можно и так. В чекаут, который out of date (именно таким чекаутом будет легковесная рабочая копия старой ревизии), коммитить нельзя. И это правильно. Но никто не мешает его изменить, и сказать ему перед коммитом update, чтобы он нагнал текущее время, и аккуратно протащил сквозь время локальные изменения.
G>>Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит. .>Ну.... поехали. .>1. Сосредоточиться. .>2. Потереть руки. .>3. Подумать о душе. .>4. git fetch origin branch .>5. ... .>6. Profit!
.>Да, действительно очень страшно. Ты спать теперь спокойно будешь?
Разумеется страшно. Ты применяешь как минимум две разных команды, мануал по второй из которых выносит неподготовленному человеку мозг,
git clone -b a repo_uri
git fetch origin b
а я обхожусь одной.
bzr branch a_uri a
bzr branch b_uri b
Но вы, фанаты гита, такие отважные парни. Ничего не боитесь.
G>>В bzr все просто до скуки. .>Фу, скучный этот ваш bzr.
Зато ваш гит веселый, обхохочешься.
G>>Один раз делаешь вот это: G>>
G>>D:
G>>cd \
G>>bzr init-repo
G>>
G>>После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить. .>В смысле? Ты с нуля что ли репо создаёшь, не забираешь чьи-то исходники? .>В гите это делается даже короче на 5 символов:
В гите аналогичная операция не делается вообще. Там другая концепция репозитория.
G>>Что мне надо знать, чтобы добиться аналогичного в git? .>Да вроде ничего особенного, доки прочитать, найти синтаксис аналогичных команд.
То есть, ты не знаешь. Понятно.
.>>>git clone -b branchName git_repo_on_same_filesystem G>>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch. .>А какая принципиальная разница?
Принципиальная разница в том, что это совсем разные вещи, не имеющие между собой ничего общего. Бранч может не иметь рабочей копии. Или иметь их тысячу. Одна рабочая копия может переключатся между разными бранчами. Операция на бранче не обязана обновлять его рабочие копии, даже если они у бранча есть.
.>Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно.
Ну, я уже привел примеры ситуаций, зачем это может быть нужно.
.>>>Правда не представляю накой такое нужно. G>>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или... .>ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять.
Какая разница, как оно там внутри — одно и тоже, или не одно и тоже, если с человеческой точки зрения понятия разные.
G>>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна? G>>Кстати, а что будет с хардлинками под вендой? .>Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов).
Где — там? Зачем указывается? Какой от этого прок?
.>Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов.
Это фича файловой системы, пользуясь которой git ускоряет тебе клонирование на локальной ФС.
Thanks to hardlinking, local clones require less time and space than a plain backup.
G>>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча". .>>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей. G>>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает? .>Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.
Cудя потому, что я знаю про то, как оно устроено (а оно устроено на хардлинках), с перечисленным мной выше у git будут определенные проблемы.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, MaxLovic, Вы писали:
ML>>У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
A>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места.
Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
Здравствуйте, MaxLovic, Вы писали:
ML>Добрый день.
ML>Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети.
Если svn всем устраивает и нужно только дублирование — "svnadmin hotcopy" спасет отца русской демократии. Позволяет создать зеркало репозитария и далее его инкрементально обновлять, т.е. при повторном запуске копироваться будут только новые ревизии.
Само зеркало положить в dropbox или аналоги, на флешку, да куда угодно. Единственное — это именно архивная копия, работать с ней напрямую нельзя — сначала коммитим в "исходную" репу, потом по hotcopy синхронизируем зеркало.
Здравствуйте, MaxLovic, Вы писали:
ML>У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. Во многих компаниях это обходят тем, что разделяют репы по назначению — релизные (держат только стабильные версии), по фичам (коммитят только дельту по отдельным большим задачам), по проектам (коммиты по направлениям работы) и т.п.
Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети.
Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
Попробовал mercurial, немного удобнее под виндой, но функционал тот же.
Сейчас единственным вариантом вижу залить свой svn репозиторий (папку на жестком диске) в гит репозиторий и периодически делать commit и pull. Но решение какое-то кривое.
Может есть какие еще VCS для моих задач? Или может я не полностью разобрался с git и с его помощью можно организовать такой же рабочий процесс?
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, MaxLovic, Вы писали:
ML>>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
A>Кто мешает сделать несколько репозиториев, по числу проектов? Независимо от используемой системы контроля версий это вполне работающая схема.
У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
Здравствуйте, MaxLovic, Вы писали:
ML>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
Кто мешает сделать несколько репозиториев, по числу проектов? Независимо от используемой системы контроля версий это вполне работающая схема.
Здравствуйте, MaxLovic, Вы писали:
ML>Добрый день.
ML>Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети. ML>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах. ML>Попробовал mercurial, немного удобнее под виндой, но функционал тот же.
ML>Сейчас единственным вариантом вижу залить свой svn репозиторий (папку на жестком диске) в гит репозиторий и периодически делать commit и pull. Но решение какое-то кривое. ML>Может есть какие еще VCS для моих задач? Или может я не полностью разобрался с git и с его помощью можно организовать такой же рабочий процесс?
а чем svn не устраивает?
Здравствуйте, SаNNy, Вы писали:
SNN>Здравствуйте, MaxLovic, Вы писали:
ML>>Может есть какие еще VCS для моих задач? Или может я не полностью разобрался с git и с его помощью можно организовать такой же рабочий процесс? SNN>а чем svn не устраивает?
Устраивает, но репозиторий хранится у меня на диске. Чтобы не пропало, надо делать бэкап, не очень удобно. Поэтому хотел перейти на распределенную систему контроля версий, чтобы копия репозитория была у меня на диске и в сети.
Может какой-нить Bazaar поддерживает работу с частью репозитория и externals?
ML>Устраивает, но репозиторий хранится у меня на диске. Чтобы не пропало, надо делать бэкап, не очень удобно. Поэтому хотел перейти на распределенную систему контроля версий, чтобы копия репозитория была у меня на диске и в сети. ML>Может какой-нить Bazaar поддерживает работу с частью репозитория и externals?
А что мешает положить репозиторий на какой-нить бесплатный хостинг репозиториев типа assembla?
Здравствуйте, Eye of Hell, Вы писали:
ML>>Устраивает, но репозиторий хранится у меня на диске. Чтобы не пропало, надо делать бэкап, не очень удобно. Поэтому хотел перейти на распределенную систему контроля версий, чтобы копия репозитория была у меня на диске и в сети. ML>>Может какой-нить Bazaar поддерживает работу с частью репозитория и externals?
EOH>А что мешает положить репозиторий на какой-нить бесплатный хостинг репозиториев типа assembla?
Да, как раз так сделал. Тока дампы надо будет снимать с него себе на диск.
EOH>>А что мешает положить репозиторий на какой-нить бесплатный хостинг репозиториев типа assembla?
ML>Да, как раз так сделал. Тока дампы надо будет снимать с него себе на диск.
Assembla will be back soon
We are busy upgrading assembla with technology and features for you & will be back shortly.
Здравствуйте, Gaperton, Вы писали:
G>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
Занятно, спасибо, надо бы ознакомиться с ним поближе.
Здравствуйте, Aquary, Вы писали:
G>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
A>Занятно, спасибо, надо бы ознакомиться с ним поближе.
Ключевые слова в этом разбирательстве — "shared repository".
Здравствуйте, Gaperton, Вы писали:
A>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
А в каких нет? git тоже умеет, умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет).
У svn, единицей фетча является одна ревизия одного каталога, в распределённых обязательно нужно клонировать все каталоги, что создаёт трудности при переезде массивного svn репозитория в распределённую систему контроля.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
A>>>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей. .>>А в каких нет? git тоже умеет, G>Ага. А когда я второй бранч того же проекта таким образом захочу "склонировать" — он ляжет в другой репозиторий, и у меня еще разок полностью прокачается его полная история. Удобно.
Зачем? Закачай бранч в тот же репо, скачаются только отсутствующие коммиты.
.>>умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет). G>В bzr понятия бранча, репозитория, и рабочей копии полностью независимы, и ими очень просто манипулировать раздельно. В отличии от.
Тоже есть shared repository. Рабочая копия, репозиторий и индекс тоже можно разделить. Только непонятно зачем — клоны могут использовать хардлинки для легковесности.
G>bzr chechout --lightweight branch_path working_copy_path
git clone -b branchName git_repo_on_same_filesystem
Правда не представляю накой такое нужно. Обычно бранчи переключать приходится в одном и том же месте, т.к. всё окружение настроено туда.
G>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.
.>>У svn, единицей фетча является одна ревизия одного каталога, в распределённых обязательно нужно клонировать все каталоги, что создаёт трудности при переезде массивного svn репозитория в распределённую систему контроля. G>В bzr не создает. G>bzr branch http://sources/svn/my-repo/and/any/path my_branch_name
Вот это удобно... в гите похоже такое не получается сделать из-за того, что коммиты могут подписываться — соответсвенно если забирать только часть файлов — всё сломается.
G>Могу произвольным образом SVN-репозиторий на бранчи нарезать, и разложить эти бранчи по репозиториям так же произвольно — как мне захочется. После чего — легко и непринужденно между репозиториями их перекидывать, и push-ить результаты из любого места обратно в SVN. Все это стандартными командами, отличие только в том что иногда url-е будет указывать в SVN.
G>А как там в ваших гитах — не знаю. Помню, что как-то сильно сложно.
Бранчи резать по репозиториям и гит прекрасно умеет, а вот резать репозиторий по каталогам... как-то делается, вроде, но сложно. И мне непонятно как всякие мержи будут в таком случае работать — коммиты же тоже делить надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
G>Начнем с того, что он умеет работать с твоим svn-репозиторием, как со своим собственным, из коробки, без каких-либо плагинов. То есть, во всех командах bzr ты можешь указывать в качестве бранча путь к своему svn-репозиторию, и все будет прекрасно работать.
Немного не так.
1) Плагины все-таки есть, по крайней мере под Ubuntu помимо пакета bzr для работы с svn надо ставить bzr-svn, а для интерфейса — qbzr.
2) Указывать в качестве бранча путь к svn-репозиторию тоже не всегда получиться, в ряде случаев необходимо добавлять префикс "svn+".
In some cases, this request fails. This seems to be more common with https:// style links, than regular HTTP links. If this happens to you, just prefix the URL with svn+, such as svn+https://. This will tell bzr-svn to bypass the probe and treat the URL as Subversion repository.
Здравствуйте, Gaperton, Вы писали:
G>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
Потестил тут... Короче, эта "фича" нафиг гиту не нужна, ибо и так всё быстро работает.
git clone -s myrepo mynewrepo
Выполнилось для 6.5Гб репозитория за 42 секунды. каталог ".git" клона — 1Мб. Там есть вся история, все бранчи из источника.
Притом, ~41 секунду выполнялся чекаут — 1600 каталогов и 6200 файлов, общим размером 130 мегов, по времени практически совпадает с обычным копированием через Проводник.
Переключение между ветками: 1-6 секунд, в зависимости от разницы между ними. 6 секунд заняло переключение 2 бранчей с разницей в 1200 файлах.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Grelkin, Вы писали:
G>Немного не так.
G>1) Плагины все-таки есть, по крайней мере под Ubuntu помимо пакета bzr для работы с svn надо ставить bzr-svn, а для интерфейса — qbzr.
Под вендой и макосью все работает из коробки. То есть, соответствующие плагины изначально вложены в инсталлятор. Поэтому, я и говорю людям, что работает из коробки без плагинов, подразумевая, что ничего специального доставлять не требуется.
G>2) Указывать в качестве бранча путь к svn-репозиторию тоже не всегда получиться, в ряде случаев необходимо добавлять префикс "svn+".
Ну, это не так уж страшно. Кстати, спасибо, буду теперь на всякий случай добавлять svn+ всегда.
Здравствуйте, ., Вы писали:
.>Здравствуйте, Gaperton, Вы писали:
G>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча". .>Потестил тут... Короче, эта "фича" нафиг гиту не нужна, ибо и так всё быстро работает.
Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.
Данная фича полезна для быстрого вынимания из репозитория конкретной ревизии по нужде, с целью, например, воспроизведения ошибки, проявляющейся в конкретной версии. Создать рабочую копию, вынув из репа исходники — это естественно и понятно. Клонировать в этой ситуации репозиторий, потому что это "быстро работает" — контринтуитивно как-то.
Здравствуйте, Gaperton, Вы писали:
G>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.
Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее.
G>Данная фича полезна для быстрого вынимания из репозитория конкретной ревизии по нужде, с целью, например, воспроизведения ошибки, проявляющейся в конкретной версии. Создать рабочую копию, вынув из репа исходники — это естественно и понятно. Клонировать в этой ситуации репозиторий, потому что это "быстро работает" — контринтуитивно как-то.
А если вперёд-назад по коммитам походить захочешь, что-то поменять там чуть, а потом помержить туда-сюда?
G>Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит.
Ну.... поехали.
1. Сосредоточиться.
2. Потереть руки.
3. Подумать о душе.
4. git fetch origin branch
5. ...
6. Profit!
Да, действительно очень страшно. Ты спать теперь спокойно будешь?
G>В bzr все просто до скуки.
Фу, скучный этот ваш bzr.
G>Один раз делаешь вот это: G>
G>D:
G>cd \
G>bzr init-repo
G>
G>После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить.
В смысле? Ты с нуля что ли репо создаёшь, не забираешь чьи-то исходники? В гите это делается даже короче на 5 символов:
git init
остальное — то же самое.
G>Что мне надо знать, чтобы добиться аналогичного в git?
Да вроде ничего особенного, доки прочитать, найти синтаксис аналогичных команд.
.>>git clone -b branchName git_repo_on_same_filesystem G>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.
А какая принципиальная разница?
Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно.
.>>Правда не представляю накой такое нужно. G>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или...
ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять.
G>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна? G>Кстати, а что будет с хардлинками под вендой?
Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов).
Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов.
G>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча". .>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей. G>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?
Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
G>>>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно. .>>Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее. G>Это у вас в гите все кругом дело привычки. А в bzr можно выбирать между обоими способами по ситуации.
В git тоже. Я говорю, что мне удобнее в одном каталоге держать и переключаться. Сделать можно несколько, но не понимаю зачем. Для svn/cvs — я понимал, т.к. тормозило. В git — не тормозит, поэтому делаю как удобно. Судя по этому, bzr в таком сценарии работает в 80 раз медленнее. Если правда, то понятно, что тебе приходится "выбирать" по ситуации.
G>Можно и так. В чекаут, который out of date (именно таким чекаутом будет легковесная рабочая копия старой ревизии), коммитить нельзя. И это правильно. Но никто не мешает его изменить, и сказать ему перед коммитом update, чтобы он нагнал текущее время, и аккуратно протащил сквозь время локальные изменения.
Ты же так выбор любишь, а тут то нелзья, сё нельзя. В гите можно и закоммитить, а потом замержить, или сделать новую ветку потом, или делать rebase для "протаскивания времени", или тупо выбросить и забыть, если лажа вышла.
G>Разумеется страшно. Ты применяешь как минимум две разных команды, мануал по второй из которых выносит неподготовленному человеку мозг,
А что делать — фич очень много, я знаю наверное только половину, реально использовал наверное только треть. Но наличие неизвестных фич не мешает использовать удобные.
G>
G>git clone -b a repo_uri
G>git fetch origin b
G>
G>а я обхожусь одной.
git clone repo_uri
делается один раз для проекта (аналог bzr init-repo с вытягиванием данных из удалённого репо одной командой). За кулисами делается примерно следующее:
git init (новый репо, создание каталога ".git")
git remote add origin repo_url(говорим гиту, что хотим работать с удалённым репо repo_url, можно работать с несколькими одновременно)
git fetch origin (выкачиваем содержимое по сети)
git checkout master (в рабочую копию помещаются файлы из ветки удалённой master).
Как-то так.
clone это просто удобная процедурка, совмещающая кукчу boilerplate команд.
G>
G>bzr branch a_uri a
G>bzr branch b_uri b
G>
потом "git checkout a", "git checkout b". Вытаскивать бранчи отдельно смысла нет.
Ты просто нештатный юскейс спросил. Так под гитом делать можно, опускаясь до более low-level команд, но нафиг не нужно.
G>Зато ваш гит веселый, обхохочешься.
А что, плакать что-ли?
G>В гите аналогичная операция не делается вообще. Там другая концепция репозитория.
Опиши, плз. Или ссылку хорошую хотя бы...
G>>>Что мне надо знать, чтобы добиться аналогичного в git? G>То есть, ты не знаешь. Понятно.
Не знаю чего именно ты хочешь добиться. Если тупо чтобы git работал как bzr, то я думаю это невозможно по понятным причинам. А "как решить проблему А" — может и знаю, если что, могу и нагуглить.
.>>>>git clone -b branchName git_repo_on_same_filesystem G>>>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch. .>>А какая принципиальная разница?
G>Принципиальная разница в том, что это совсем разные вещи, не имеющие между собой ничего общего. Бранч может не иметь рабочей копии. Или иметь их тысячу. Одна рабочая копия может переключатся между разными бранчами. Операция на бранче не обязана обновлять его рабочие копии, даже если они у бранча есть.
Я имею в виду чем клонирование репо в новый каталог с созданием рабочей копии там же отличается от "вынимания рабочей копии".
.>>Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно. G>Ну, я уже привел примеры ситуаций, зачем это может быть нужно.
Ты привёл ситуацию, когда нужно взять либо только бранч А, либо только бранч Б для экономии (?) трафика, места. В гите можно сразу взять все бранчи А-Я и быстро переключаться между ними по желанию левой пятки, экономить ничего не надо.
Или ты о чём?
.>>>>Правда не представляю накой такое нужно. G>>>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или... .>>ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять. G>Какая разница, как оно там внутри — одно и тоже, или не одно и тоже, если с человеческой точки зрения понятия разные.
С человеческой точки зрения тоже нет принципиальной разницы — бранч называется "my_experiments", ревизия называется "74b817e". Просто удобнее имя, все команды понимают одинаково и то, и то.
G>>>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна? G>>>Кстати, а что будет с хардлинками под вендой? .>>Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов). G>Где — там? Зачем указывается? Какой от этого прок?
В shared-клоне. Этот клон — легковесный, он не содержит данных, а просто путь к ним. Но при этом он полнофункиональный — все ветки, мержи как хочешь, етс.
.>>Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов. G>Это фича файловой системы, пользуясь которой git ускоряет тебе клонирование на локальной ФС. G>
G>Thanks to hardlinking, local clones require less time and space than a plain backup.
Вот я и говрю, shared-клон зависим от основного — если он сломается/потеряется, то кирдык. Но для флешек/фат — самое то. А hardlinking клон — работает в пределах одной ФС, создаёт независимые клоны — бекап.
G>>>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча". .>>>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей. G>>>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает? .>>Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.
G>Cудя потому, что я знаю про то, как оно устроено (а оно устроено на хардлинках), с перечисленным мной выше у git будут определенные проблемы.
Нет, shared клон содержит просто путь, нету никаких хардлинков.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
. Приведи листинг заклинаний git-а, который это выполнит. 
