Размер репозитория в гите может быть меньше размера локальной копии SVN'а. Надо проверить это для вашего случая. Возможно, что никаких настроек глубины и не потребуется.

A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it)

man git clone

Это в версии 1.7.0.4. Может что-то поменяли?

Для таких размеров dvcs не рекомендую.

А я рекомендую. Но хитрую, с подвыпердыхтом - clearcase.

> Как у TortoiseGit со стабильностью?

У TortoiseHg, говорят, всё нормально :)

Не катит.

Для таких размеров dvcs не рекомендую.

Понятно.

А как у меркуриала с 50 гигабайтными репами? ;)

>А как у меркуриала с 50 гигабайтными репами? ;)

Фанбои в любом случае скажут, что отлично (на то они и фанбои), но словам этим грош цена. Как и утверждениям про стабильность tortoisehg.

> А как у меркуриала с 50 гигабайтными репами? ;)

ХЗ. А где в топике 50Г репозитории _именно Mercurial_? А из 5Г локальной копии SVN половина - это text bases. Насколько я понимаю, главной проблемой будет diff на многомегабайтных (двоичных?) файлах, а тут уже DVCS ничем не поможет.

И да, миграция с SVN на Mercurial гораздо легче, чем на Git.

> Как и утверждениям про стабильность tortoisehg.

Слова вообще недорого стоят. Но особенно дешевы слова, под которыми нет подписи :D

Мы на работе переводили всё с svn на git.

Оказалось, что working copy в svn занимает больше чем вся история в git. Хотя проекты большие и с долгой историей. Git хранит историю очень компактно.

TortoiseGit я лично не пользовал, видел у коллег. Нареканий нет. Разве что rebase непонятно как делать.

Если есть такая возможность, йентральный репозиторий лучше делать на unix. Если же нету — ставьте cygwin (ssh). Это самый безболезненный вариант.

На клиенте проще msysgit, не надо ничего настраивать.

>У TortoiseHg, говорят, всё нормально :)

Поддерживаю. Mercurial выглядит лучше под Windows.

> У git'а есть опция --depth, можно ли [...] на клиенте всегда иметь примерно одну копию, в смысле срез репозитария примерно одной ревизии?

Можно, только это будет уже не репозиторий, а именно что срез. С этим огрызком ничего сделать будет нельзя, ни pull, ни push.

Что же можно сделать?

Можно, только это будет уже не репозиторий, а именно что срез. С этим огрызком ничего сделать будет нельзя, ни pull, ни push.

А что можно сделать, чтобы с огрызком можно было хоть что-то делать? Хочется не хранить на клиентах весь репозиторий целиком, потому что к истории обращаются редко.

GNU is not Unix.

йентральный репозиторий лучше делать на unix.

Тут вопрос использования Windows даже не стоит, строго GNU/Linux.

Можно, только это будет уже не репозиторий

Правда? Это будет обычный репозиторий.

С этим огрызком ничего сделать будет нельзя, ни pull, ни push.

Можно будет делать и pull и push.

А что можно сделать, чтобы с огрызком можно было хоть что-то делать?

Ничего не надо делать. Shallow репозиторий для разработчика ничем не отличается от полного, разве что куцой историей. git pull и git push работают как обычно.

http://www.kernel.org/pub/software/scm/git/docs/git-clone.html

--depth <depth>

Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

Ы?

git однозначно будет лучше. И репы он сжимает. Но на винде стабильного ничего нет. Mercurial тоже самое, только медленнее, но лучше поддержка винды.

Ы?

Здесь имеются в виду ограничения, когда shallow репозиторий находится на удаленной стороне.

Прежде чем ыкать, мог бы и попробовать ради интереса.

Пользовался TortoiseGit для простых вещей - все ок. Чего-то веселого не пробовал. Если миграция с SVN, то для простых вещей типа pull/push/diff и т.д. никаких проблем.

Правда, надо оговориться, push из shallow репозитория работает только если у коммита будет правильный предок, такой же как и в удаленном репо. Для простого случая — push в master, это справедливо, если рассматривать push в удаленные бранчи, то начинает болеть голова.

Ну ладно, пусть так.

Вот, например статистика годичной давности по Гному: http://blogs.gnome.org/simos/2009/04/18/git-clones-vs-shallow-git-clones/ Видно, что экономия от использования shallow реп копеечная. Цимеса никакого, а проблем куча.

Вот, например статистика годичной давности по Гному

Они оговаривают, что хранят много бинарных данных под контролем версий. В случае ТС — «не скажу что файлов много, но они большие, до десятков мегабайтов» — очень похоже на такую же ситуацию, поэтому действительно надо просто оценить эффект.

Касательно проектов с большой историей и, в основном, текстовыми файлами, shallow clone может быть выходом их ситуации.

Хотя, если в команде нет git джедая, то процесс может развалится на куски. Саботаж и подобные прелести. Тем более под виндой. Очень много надо потратить на исследование незнакомой инфраструктуры.