LINUX.ORG.RU

О git на Windows.


0

0

Задумался об использовании git на вендовых машинах. Сейчас люди используют SVN и TortoiseSVN. Поскольку проекты довольно крупные (не скажу что файлов много, но они большие, до десятков мегабайтов) хочется попробовать git. Но есть вопросы. Итак:

На клиентах не надо хранить репозитарий целиком, потому что он очень большой. Размер локальной копии SVN'а ~5 гигабайтов, размер репозитория ~50 гигабайтов и растёт. У git'а есть опция --depth, можно ли однажды прописав её в конфигурационном файле или настройках (напомню речь идёт о Windows, msysgit и TortoiseGit) на клиенте всегда иметь примерно одну копию, в смысле срез репозитария примерно одной ревизии?

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

★★★★★

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

dmitry_vk ★★★ ()

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. Может что-то поменяли?

Nao ★★★★★ ()
Ответ на: комментарий от Reset

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

anonymous ()
Ответ на: комментарий от Reset

Не катит.

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

Понятно.

Camel ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

anonymous ()
Ответ на: комментарий от LamerOk

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

tailgunner ★★★★★ ()

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

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

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

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

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

k_andy ★★★ ()
Ответ на: комментарий от tailgunner

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

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

zootcat ()

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

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

akk ★★★★★ ()
Ответ на: комментарий от akk

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

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

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

Camel ★★★★★ ()
Ответ на: комментарий от k_andy

GNU is not Unix.

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

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

Camel ★★★★★ ()
Ответ на: комментарий от akk

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

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

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

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

baverman ★★★ ()
Ответ на: Что же можно сделать? от Camel

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

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

baverman ★★★ ()
Ответ на: комментарий от baverman

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.

Ы?

akk ★★★★★ ()

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

vertexua ★★★★☆ ()
Ответ на: комментарий от akk

Ы?

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

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

baverman ★★★ ()

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

Pavval ★★★★★ ()
Ответ на: комментарий от akk

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

baverman ★★★ ()
Ответ на: комментарий от baverman

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

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

akk ★★★★★ ()
Ответ на: комментарий от akk

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

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

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

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

baverman ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.