Comments 36
Под кат, пожалуйста.
чем гит лучше моего svn сервера? для меня это самвй важный вопрос.. я почитал и совсем немножко представляю его отличия, но пока не вижу реальной выгоды. а вы?
Возьмите и попробуйте поработать сами. Иначе тут будет холивар и разговор глухого со слепым.
от меня - не будет.. я же вашего субъективного мнения спрашиваю, мне интересно. просто для мало того, что ror переехал на git :) я хочу понять зачем это стоит делать кроме "расширения кругозора", потому что svn и git - вторичные инструменты и просто так переходить не хочется.
Для меня было две практических причины перейти с svn на mercurial для своих проектов:
- в distributed scm намного лучше дела с бранчами
- не надо париться с бекапами каждая рабочая копия уже независимый бэкап репозитория
- в distributed scm намного лучше дела с бранчами
- не надо париться с бекапами каждая рабочая копия уже независимый бэкап репозитория
по поводу первого пункта, нельзя–ли поподробнее? Что конкретно намного лучше ? Я конечно про сравнение с svn 1.5
А какая запарка с бэкапами у вас в svn? Это одна комманда в крон, ну или 5 минут на организацию полного зеркала
А какая запарка с бэкапами у вас в svn? Это одна комманда в крон, ну или 5 минут на организацию полного зеркала
Сразу скажу имхо, действительно серьезные и объективные преимущества у DVCS есть svn есть только в достаточно распределенных проектах. Ну или люди говорят, удобно в большой команде более точно можно контролировать доступ к основной ветке. Вроде того что у каждого тимлида по ветке, они сливают туда изменения от подчиненных, делают review, а потом Самый Главный Лид мержит в главную ветку.
Что касается меня: да, 1.5 я еще не пробовал толком для своих нужд уже к меркуриалу привык, а на работе, прости господи, VSS. Меркуриал определенно мне нравится скоростью, маленьким размером репозитория, и тем что бранч в общем-то можно создать тупо скопировав папку с исходниками.
С зеркалами очень просто, для этого нужно два компутера, а у меня репозиторий на VDS и 3-4 компутера с которых я работаю, и ни один из них не включен круглосуточно.
Что касается меня: да, 1.5 я еще не пробовал толком для своих нужд уже к меркуриалу привык, а на работе, прости господи, VSS. Меркуриал определенно мне нравится скоростью, маленьким размером репозитория, и тем что бранч в общем-то можно создать тупо скопировав папку с исходниками.
С зеркалами очень просто, для этого нужно два компутера, а у меня репозиторий на VDS и 3-4 компутера с которых я работаю, и ни один из них не включен круглосуточно.
Лично мне Git не нравится. Собственно - git это куча скриптов, бинарников и тому подобного которое работает как одна большая scm. Плюс, не нравится что базу время от времени нужно пересобирать что бы оно не тормозило и не жрало много места.
Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.
P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.
P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
У нас на проекте использовался svn + track. Почти год назад перешли на git и жить стало легче. Так как распределенная разработка, то если пропадает связь до сервера, не беда, есть локальный репозитарий, на своем компьютере. Когда линк поднимается, можно сделать push на сервер.
"git stash"/"git stash apply" - вещь супер.
"git stash"/"git stash apply" - вещь супер.
Редкий пример хорошей статьи. Спасибо.
> Уже были статьи про основы гита, были и статьи про внутреннее устройство репозитория.
Хотелось бы ссылочек, если можно.
Хотелось бы ссылочек, если можно.
Вместо gs лучше использовать gst, ибо
$ gs --help
ESP Ghostscript 8.15.4 (2007-03-14)
$ gs --help
ESP Ghostscript 8.15.4 (2007-03-14)
Кстати, помнишь ты говорил, что "export PS1='`__git_ps1 "%s"` \w \$ '" работает только в последней версии.
маленькое замечание к 3): вместо git-stash && git-checkout && git-stash apply можно использовать git-checkout -m
UFO just landed and posted this here
Спасибо большое за статью. Будет очень интересно почитать про git-svn.
пользуюсь SVN
git отпугивает тем, что воодит новые сущности, надобность в которых сильно не ощущается
хотя сама идея децентрализованного хранилища и работы с локальным репозиторием кажется правильной
хотелось бы прочитать статью про переход на git с svn, но не типа "вместо svn up набирайте git up", а с описанием различий в базовых понятиях и подходах к работе с хранилищем.
спасибо.
git отпугивает тем, что воодит новые сущности, надобность в которых сильно не ощущается
хотя сама идея децентрализованного хранилища и работы с локальным репозиторием кажется правильной
хотелось бы прочитать статью про переход на git с svn, но не типа "вместо svn up набирайте git up", а с описанием различий в базовых понятиях и подходах к работе с хранилищем.
спасибо.
UFO just landed and posted this here
Спасибо. Попробую.
Дело в том, что я только пол года назад внедрил в своём проекте SVN: это не было слишком тягостно, но не без сопротивления "среды" ))
Если теперь я приду и скажу "SVN - это прошлый век, давайте юзать git", меня побъют ))
Внимание вопрос: как менеджерам и рядовым сотрудникам объяснить, зачем им нужно (ли) перейти с SVN на git? зачем им тратить своё время на освоение новой логики и технологии, когда они только что освоили и привыкли к SVN?
Если теперь я приду и скажу "SVN - это прошлый век, давайте юзать git", меня побъют ))
Внимание вопрос: как менеджерам и рядовым сотрудникам объяснить, зачем им нужно (ли) перейти с SVN на git? зачем им тратить своё время на освоение новой логики и технологии, когда они только что освоили и привыкли к SVN?
интересно, а усложняется ли (или вообще возможна ли) работа с git, если в репозитории нужно учитывать права доступа пользователей? т.е. разные люди имеют доступ к только к определенным директориям репозитория.
Нет, такое гит не поддерживает: вы клонируете весь репозиторий и делаете с ним, что хотите. Поддерживается лишь хранение юникс-атрибутов rwx, но это не ограничивает доступ.
Если хотите разграничить доступ — разбивайте проект на разные репозитории, кладите на защищенный сервер и ограничивайте доступ к каждому репозиторию (например, с помощью gitosis, а можно и просто юникс-средствами ограничить доступ к определенным директориям на сервере).
Если хотите разграничить доступ — разбивайте проект на разные репозитории, кладите на защищенный сервер и ограничивайте доступ к каждому репозиторию (например, с помощью gitosis, а можно и просто юникс-средствами ограничить доступ к определенным директориям на сервере).
Копию статьи Eric Goodwin (ссылка протухла) положил здесь: eagleas.livejournal.com/32478.html
В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.
Есть примерные сроки? =)
Sign up to leave a comment.
Ежедневный Git