Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети.
Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
Попробовал mercurial, немного удобнее под виндой, но функционал тот же.
Сейчас единственным вариантом вижу залить свой svn репозиторий (папку на жестком диске) в гит репозиторий и периодически делать commit и pull. Но решение какое-то кривое.
Может есть какие еще VCS для моих задач? Или может я не полностью разобрался с git и с его помощью можно организовать такой же рабочий процесс?
Здравствуйте, MaxLovic, Вы писали:
ML>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
Кто мешает сделать несколько репозиториев, по числу проектов? Независимо от используемой системы контроля версий это вполне работающая схема.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, MaxLovic, Вы писали:
ML>>Сначала, начитавших много хвалебных речей, решил перейти на git. Сформировал репозиторий, начал с ним работать, но оказалось, что гит предназначен для одного проекта, а не для хранилища всех проектов: клонировать можно только весь репозиторий полностью, а не отдельный его проект, плюс какие-то сложности с externals, которые мне нужны, поскольку мною написаны общие скрипты, используемые в нескольких проектах.
A>Кто мешает сделать несколько репозиториев, по числу проектов? Независимо от используемой системы контроля версий это вполне работающая схема.
У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
Здравствуйте, 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?
Здравствуйте, MaxLovic, Вы писали:
ML>У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. Во многих компаниях это обходят тем, что разделяют репы по назначению — релизные (держат только стабильные версии), по фичам (коммитят только дельту по отдельным большим задачам), по проектам (коммиты по направлениям работы) и т.п.
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.
Здравствуйте, 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, который позволяет работать с командной строкой, не запоминая при этом сотни флагов.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, MaxLovic, Вы писали:
ML>>У меня проектов несколько десятков. Что мне, под каждый создавать репозиторий и таскаться с ними потом. Гораздо удобнее когда все в одном месте.
A>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места.
Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
Здравствуйте, Gaperton, Вы писали:
G>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
Занятно, спасибо, надо бы ознакомиться с ним поближе.
Здравствуйте, Aquary, Вы писали:
G>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
A>Занятно, спасибо, надо бы ознакомиться с ним поближе.
Ключевые слова в этом разбирательстве — "shared repository".
Здравствуйте, Gaperton, Вы писали:
A>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
А в каких нет? git тоже умеет, умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет).
У svn, единицей фетча является одна ревизия одного каталога, в распределённых обязательно нужно клонировать все каталоги, что создаёт трудности при переезде массивного svn репозитория в распределённую систему контроля.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
A>>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места. G>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей. .>А в каких нет? git тоже умеет,
Ага. А когда я второй бранч того же проекта таким образом захочу "склонировать" — он ляжет в другой репозиторий, и у меня еще разок полностью прокачается его полная история. Удобно.
.>умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет).
В bzr понятия бранча, репозитория, и рабочей копии полностью независимы, и ими очень просто манипулировать раздельно. В отличии от.
Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>У svn, единицей фетча является одна ревизия одного каталога, в распределённых обязательно нужно клонировать все каталоги, что создаёт трудности при переезде массивного svn репозитория в распределённую систему контроля.
Могу произвольным образом SVN-репозиторий на бранчи нарезать, и разложить эти бранчи по репозиториям так же произвольно — как мне захочется. После чего — легко и непринужденно между репозиториями их перекидывать, и push-ить результаты из любого места обратно в SVN. Все это стандартными командами, отличие только в том что иногда url-е будет указывать в SVN.
А как там в ваших гитах — не знаю. Помню, что как-то сильно сложно.
Здравствуйте, MaxLovic, Вы писали:
ML>Добрый день.
ML>Уже больше года работаю с SVN на домашнем компьютере, в которой храню свои проекты. Объем проектов разросся, потерять все это не хочется, задумался над дублированием репозитория в сети.
Если svn всем устраивает и нужно только дублирование — "svnadmin hotcopy" спасет отца русской демократии. Позволяет создать зеркало репозитария и далее его инкрементально обновлять, т.е. при повторном запуске копироваться будут только новые ревизии.
Само зеркало положить в dropbox или аналоги, на флешку, да куда угодно. Единственное — это именно архивная копия, работать с ней напрямую нельзя — сначала коммитим в "исходную" репу, потом по hotcopy синхронизируем зеркало.
Здравствуйте, 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+ всегда.
