Re: Необходимость Git - Средства разработки

Сразу скажу — хотелось бы обойтись без священных войн.

Моя работа — написание программ на C# для использования на крупном предприятии (ну, т.е., "энтерпрайз"). До недавнего времени пользовался только SVN. Уже давно — лет семь. Всё устраивало. Слышал, разумеется, про git. Знаю, что он "распределенный" в отличие от "централизованного" SVN. Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Несколько раз пытался изучить git и перейти на него, но не понял, что мне это даст. Хотя, в принципе, умом понимаю, что он лучше, что VCS развиваются в этом направлении, и все такое. Недавно предложил мне коллега перейти на git (перевести наш проект). Кстати, над проектом работаем только мы двое. Может, присоединится еще пара человек.
Перевели — создали приватный репозиторий на гитхабе. Были трудности с импортом проекта из SVN, история не хотела подтягиваться. Но справились. Ок.

Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад

.
Ну ладно, в большинстве случаев он все-таки работает, и тогда работа ничем не отличается от SVN: коммиты и апдейты все те же. Только коммит разбит на две фазы — локальный коммит и пуш. В студии даже кнопочка есть — Sync, все сразу делает, чтоб два раза не нажимать. В Гиточерепахе, кстати, тоже — предлагает пушить сразу после коммита.

Теперь проблемы. Я везде читаю о том, что в гите легкий мержинг и меньше конфликтов. Практика показывает — конфликтов ровно столько же, и это неудивительно, если двое правят одно и то же, конфликт неизбежно возникнет. Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория, куда должны пушить все программисты.

Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config).
Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии. Теперь он мне пишет:

An error occurred. Detailed message: An error was raised by libgit2. Category = Tag (Error).
This transport isn't implemented. Sorry

Что я, спрашивается, должен с этим делать?

Кстати, о git --config. Пару вопросов: зачем ему мой email?? И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Плюсану, аналогичные мысли по поводу SVN/Perforce <-> Git.
Обычно успокаивают словами "вы не умеете его готовить".
Мне больше всего Gite не нравится его как раз удаленность от офиса, может канал упасть или хост, а репозитарий нужен. Не часто, но у меня есть небольшой %% сборок на билд сервере не прошедший как раз из-за недоступности репы.

Здравствуйте, dmitry_npi, Вы писали:

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания.

Берите Mercurial. Там всё в разы проще, а возможностей даже больше.

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Git в картинках

Здравствуйте, dmitry_npi, Вы писали:

_>Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад

_>An error occurred. Detailed message: An error was raised by libgit2. Category = Tag (Error).
_>This transport isn't implemented. Sorry

_>Что я, спрашивается, должен с этим делать?

Использовать более доделанный софт не вариант?

_>Кстати, о git --config. Пару вопросов: зачем ему мой email??

Гит делался разработчиками ядра Линукс для себя. У них все общение по email. Нафиг им коммиты от людей, с которыми невозможно связаться?

_>И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

Сделай в разных репозиториях разных пользователей, если надо.

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Лично я заметил следующие плюсы (из того, что реально заметно/используется)
1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.
2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
3) В git возможен коммит не всего файла, а частей.

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Так не меняй ничего, если все устраивает

Здравствуйте, dmitry_npi, Вы писали:

_>Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше.

Не совсем так. Git и svn (я говорю про свежие версии, начиная с 1.8) примерно одинаково юзабельны, но заточены под принципиально разные сценарии использования.

Svn хорош для небольших проектов, когда над репозитарием работают не больше 20-30 человек (это с аналитиками-тестерами-дизайнерами). Главные преимущества:
* концептуальная простота, для работы достаточно освоить две кнопки "Забрать изменения", "отправить на сервер".
* офигенно удобная интеграция с VisualStudio от ankhSvn. Ничего хотя бы отдалённо напоминающего по удобству PendingChanges (см первый скриншот вот тут) для других систем контроля версий нет и походу не предвидится

* Простая работа с ветками, но ровно для одного сценария: отрезали ветку, периодически забираем исправления из транка, затем сливаем свои исправления в транк. Шаг вправо-влево — лучше не пробовать.

Для более крупных проектов единственно верная схема работы с svn начинают откровенно мешать, особенно если команда распределённая и стабильного канала связи у всех участников нет.
Git позволяет организовать произвольный workflow, но за это надо платить откровенно сырыми ui-инструментами (как бы поправимо, но за два года улучшений я особо не заметил) и необходимостью обучения _всей_ команды. Если хоть один человек не читал мануал, но склонен проявлять инициативу — очень легко получить примерно такие грабли в origin/master на ровном месте.

Здравствуйте, dmitry_npi, Вы писали:

_>Сразу скажу — хотелось бы обойтись без священных войн.

Боюсь что это будет непросто

_>Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад

.
_>Ну ладно, в большинстве случаев он все-таки работает, и тогда работа ничем не отличается от SVN: коммиты и апдейты все те же. Только коммит разбит на две фазы — локальный коммит и пуш. В студии даже кнопочка есть — Sync, все сразу делает, чтоб два раза не нажимать. В Гиточерепахе, кстати, тоже — предлагает пушить сразу после коммита.

_>Теперь проблемы. Я везде читаю о том, что в гите легкий мержинг и меньше конфликтов. Практика показывает — конфликтов ровно столько же, и это неудивительно, если двое правят одно и то же, конфликт неизбежно возникнет. Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория, куда должны пушить все программисты.

Когда говорят про "легкий мержинг и меньше конфликтов" имеют в виду следующее: git позволяет переписывать историю коммитов. Это дает тебе возможность перед пушем ветки на сервер сделать rebase к текущему master, что в свою очередь приведет к тому что влитие этой ветки в master гарантированно будет fast-forward слиянием без конфликтов. Естественно при ребейзевозможны конфликты, но
1) их будешь разрешать автор кода, а не его коллеги которые без понятия что он там написал
2) Конфликты будут происходить в контексте отдельных коммитов, а не как в SVN вот у тебя ветка, вот транк и между ними тысяча изменений.

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config).

git использует существующую инфраструктуру ssh ключей. Вы в M$ мире с ней не знакомы, поэтому вам приходится заниматься нетрадиционным сексом. В Linux мире SSH ключи есть практически у каждого админа/разработчика, а то и не по одной штуке.

_>Что я, спрашивается, должен с этим делать?

Писать в саппорт автору плагина к студии, очевидно.

_>Кстати, о git --config. Пару вопросов: зачем ему мой email??

Потому что авторство коммитов никак не привязано к аутентификации/авторизации на сервере. Аутентификация на сервер обеспечивается инфраструктурой SSH. Как только ты попал внутрь, ты волен делать там что угодно. Для авторства же коммитов используется емейл.

_>И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

Смотри файл .git/config в папке своего проекта.

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Выигрыш зависит от того как в вашей команде устроен процесс разработки. Если вы используете систему контроля версий как продвинутый аналог общей папки на сервере, никакого ощутимого выигрыша вы не получите.

В то же время есть команды которые используют git довольно эффективно для собственного процесса. Из того что применяется довольно часто:
1. Линейная история коммитов в человеко-читаемом виде
2. Code review на основе pull requests
3. Feature branches (в SVN это ужасный геморрой со слияниями)
4. Несколько серверных репозиториев (например, для команды и для заказчика) между которыми передаются строго определенные изменения (например, в репозиторий заказчика попадает только тот код за который он заплатил)

Здравствуйте, Dym On, Вы писали:

DO>Git в картинках

> Git гораздо быстрее Subversion.
SVN достаточно быстр для меня, а на скорость скачивания из интернета, где находится центральный репо, git не влияет.

> Git репозиторий в десятки раз компактней репозиториев Subversion (примерно в 30 раз меньше на примере проекта Mozilla).
У нас свой сервер с обыкновенным (т.е. большим жестким диском), размер репо на сервере мне безразличен, а на клиенте SVN держит только чистые копии, а не все хранилище.

> Git с самого начала разрабатывался как распределённая система контроля, позволяющая каждому разработчику иметь полный локальный контроль над репозиторием.
История разработки не является фактическим аргументом ЗА или ПРОТИВ.

> Ветки (branches) в Git гораздо легче и работают значительно быстрее.
SVN тоже хранит только дельты, про скорость см. выше.

Здравствуйте, Нахлобуч, Вы писали:

Н>Берите Mercurial. Там всё в разы проще, а возможностей даже больше.
Спасибо, буду пробовать.

Н>Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.
Да, в SVN рекомендуется делать бэкап рабочей копии перед сложным апдейтом. Однако, замечу, что настолько сложные апдейты бывают редко, в основном, когда разраб забил на практики и месяцами не синхронизировался. Получается, что GIT и Hg заставляют делать как бы бэкап, а в SVN это остается на совести пользователя. И тут получаем зеркальный аргумент — конвенции, оказывается, нужно соблюдать как в GIT, так и в SVN.

Если вы не понимаете преимуществ git'a или они для вас не критичны/не актуальны и при этом svn устраивает, то и не меняйте ничего, пользуйтесь svn. Svn не умер, вполне себе развивается, новые фичи добавляются. Зачем менять инструмент, если выигрыш от нового не очевиден?

Здравствуйте, Dym On, Вы писали:

DO>Если вы не понимаете преимуществ git'a или они для вас не критичны/не актуальны и при этом svn устраивает, то и не меняйте ничего, пользуйтесь svn. Svn не умер, вполне себе развивается, новые фичи добавляются. Зачем менять инструмент, если выигрыш от нового не очевиден?

Меня смущает, что все в инете хвалят, теперь и коллега на работе хвалит, а я не понимаю. Не хочется казаться ретроградом или тупым.

Здравствуйте, dmitry_npi,

Я думаю, что дело в том, что Вы не используете git напрямую, а пользуетесь всякими надстройками — плагин в студии, тортуизгит, клиент гитхаба. Эти надстройки либо пытаются работать одинаково со всеми VC, сводя на нет преимущества гита, либо заточены под особенности организации процесса разработки на конкретном сервисе (github заточен под open source). Используйте git напрямую, из коммандной строки, это сильно улучшит впечатление. Это не очень сложно, для повседневной работы нужно знать пордка пяти-десяти комманд, запоминается очень быстро, сначала можно держать под рукой шпаргалку.

Второй важный момент — если в других проектах ветки — это способ решить какую-то проблему, экстраординарный инструмент, то в гите ветка — базовый повседневный инструмент, идеология и процесс получаются организованы несколько иначе. Понять этот процесс сложно, если не попробовал, поэтому, мне кажется, нужно поначалу просто заставлять себя каждое мелкое изменение делать в отдельной ветке, и сливать его в основную ветку когда оно закончено, даже если использование веток не кажется осмысленным. Практика очень быстро покажет преимущества такого подхода, потом от него уже сложно будет отказаться.

Третий момент — github все-таки заточен под опенсорс, над которым работают много независимых лруг от друга разработчиков, там много отвлекающего и не нужного, bitbucket все-таки для закрытого проекта с 2 разработчиками заметно удобнее, как мне кажется.)

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

_>Меня смущает, что все в инете хвалят,
Не надо смущаться, это всего лишь значит что, для их целей git подходит лучше.

_>теперь и коллега на работе хвалит, а я не понимаю.
Вот пусть и объяснит преимущества.

_>Не хочется казаться ретроградом или тупым.
Разумный подход к выбору инструментов не делает из вас ретрограда.

Здравствуйте, dmitry_npi, Вы писали:

_>Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.

Нет, слияние производится в рабочей копии.

_>Получается, что GIT и Hg заставляют делать как бы бэкап, а в SVN это остается на совести пользователя. И тут получаем зеркальный аргумент — конвенции, оказывается, нужно соблюдать как в GIT, так и в SVN.

Это не совсем бэкап. Вернее, совсем не бэкап. Для того, чтобы сработал мердж, нужно уметь однозначно идентифицировать всех предков, чего без явного коммита изменений не выйдет.

Здравствуйте, Temnikov, Вы писали:

T>Мне больше всего Gite не нравится его как раз удаленность от офиса, может канал упасть или хост, а репозитарий нужен. Не часто, но у меня есть небольшой %% сборок на билд сервере не прошедший как раз из-за недоступности репы.

Вообще-то при сравнении централизованной системы (Subversion) и распределенной системы (Git), все с точностью до наоборот — если недоступен репозиторий централизованной системы, то ... ничего и не получится. А в распределенной системе программист, как правило, использует локальный клон удаленного репозитория, и спокойно с ним работает (просматривает историю, фиксирует изменения ит.п.). И по мере необходимости синхронизирует его с удаленным репозиторием.

Здравствуйте, Хон Гиль Дон, Вы писали:

_>>Что я, спрашивается, должен с этим делать?

ХГД>Использовать более доделанный софт не вариант?

Я предпочитаю неинтегрированные в Студию средства работы с репозиторием (хватило VSS в свое время). Для гита мне понравился SmartGit, удобно работать с несколькими разными проектами.

ХГД>Лично я заметил следующие плюсы (из того, что реально заметно/используется)
ХГД>1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.
ХГД>2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
ХГД>3) В git возможен коммит не всего файла, а частей.

ИМХО стоит упомянуть про stash — чертовски удобная штука, которой не хватало в Свине.
Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

Здравствуйте, dmitry_npi, Вы писали:

_> Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Хоть я сам предпочитаю Git и согласен, что в целом он намного лучше и удобнее, всё же должен предупредить, что возможности SVN он полностью не перекрывает.
1. Если в репозитории есть регулярно меняющиеся бинарные файлы, гиту от них может стать хреново (будет тормозить, а то и отказываться клонировать репозиторий). Некие костыли есть, но работать с ними не очень комфортно. С SVN, правда, я лично не сравнивал, но слышал, что он к бинарникам относится терпимее.
2. В SVN можно на время залочить файл, внести изменения и потом разлочить. Это гарантирует, что, во-первых, никто не сможет вклиниться в серёдку рабочего процесса и вызвать необходимость мёрджа, и во-вторых (что, пожалуй, важнее), у всех будет информация, что именно этот файл в данный момент редактируется, и вместо того, чтоб начать править его "прям ща", лучше подождать, пока сотрудник не закоммитит. Особенно полезно, опять же, в случае правки бинарных файлов (например, doc/xls/odt/pdf), которые мёрджить затруднительно. У гита же, как и у любой распределённой системы, такой функциональности не может быть в принципе. У каждого свой репозиторий, и даже если бы был какой-то флажок "занятости" файла, синхронизировать этот флажок принудительно во все клоны невозможно (комп может быть банально отрезан от сети).

P.S. Да, я согласен, что второй пункт — это палка о двух концах. Сами не раз нарывались, что кто-то залочил файл и ушёл в отпуск / заболел / уволился (к счастью, есть принудительный анлок); и что для команды в 10 человек это подходит, а когда 1000 человек, будешь сто лет ждать очереди; и так далее. Важно не это, а что такая возможность в принципе имеется, а как ей пользоваться — детали организации рабочего процесса.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

Не в порядке спора

В SVN для этого просто используются выборочные коммиты. Ну или changelists, если файлов много. Это чисто локальная штука, представляет из себя просто список файлов. В UI файлы отображаются группами (как пример — нижний скриншот вот тут). При коммите выбираем только нужные changelist, коммитим.

Для более-менее долгих задач удобней всё-таки полноценные ветки, тут dvcs побеждают с диким отрывом

Справедливости ради, в svn свитч с ветки на ветку не так быстр, как в git, но тоже терпимо. От полуминуты на мелком проекте до 10-15 минут на гигабайтах исходников (это вместе с поиском ветки в repository browser, он в tortoiseSvn знатно тупит).

Здравствуйте, Stanislav V. Zudin, Вы писали:

ХГД>>Использовать более доделанный софт не вариант?

SVZ>Я предпочитаю неинтегрированные в Студию средства работы с репозиторием (хватило VSS в свое время). Для гита мне понравился SmartGit, удобно работать с несколькими разными проектами.

Так неинтегрированные для гита как раз обычно и есть более доделанные

Мне, например, тортилы почти всегда хватает, изредка только пользуюсь Git GUI — если надо коммитить не файлы целиком, а отдельные изменения.

SVZ>ИМХО стоит упомянуть про stash — чертовски удобная штука, которой не хватало в Свине.
SVZ>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

Ну, при работающих ветках стэш — несущественная мелочь, по-моему. Всегда можно сделать новую локальную ветку, закоммитить туда недоделки, вернуться в основную ветку, сделать срочную задачу и переключиться на недоделки. Потом влить локальную ветку в мастер и удалить. Со стэшем получается меньше телодвижений, но лично мне это не принципиально.

Здравствуйте, CaptainFlint, Вы писали:

CF>Хоть я сам предпочитаю Git и согласен, что в целом он намного лучше и удобнее, всё же должен предупредить, что возможности SVN он полностью не перекрывает.
CF>1. Если в репозитории есть регулярно меняющиеся бинарные файлы, гиту от них может стать хреново (будет тормозить, а то и отказываться клонировать репозиторий). Некие костыли есть, но работать с ними не очень комфортно. С SVN, правда, я лично не сравнивал, но слышал, что он к бинарникам относится терпимее.

С бинарниками ж вроде гит в последнее время терпимо работает. Т.е., пару лет назад вообще вилы были (мы еще с SVN'овских времен храним в репозитории собранные либы — буст и прочее), иногда коммиты обламывались по нехватке памяти и прочие чудеса творились. А сейчас, тьфу-тьфу, просто тормозит. Но, по-моему, эта скорость вполне на уровне обычной скорости SVN.

	От:	dmitry_npi
	Дата:	16.10.14 06:39
	Оценка:

	От:	Temnikov
	Дата:	16.10.14 06:47
	Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	16.10.14 07:12
Оценка:	+2 -2

	От:	Dym On
	Дата:	16.10.14 07:28
	Оценка:

	От:	Хон Гиль Дон
	Дата:	16.10.14 07:38
	Оценка:	+4

	От:	slava_phirsov
	Дата:	16.10.14 09:33
	Оценка:	+5

	От:	Stanislav V. Zudin
	Дата:	16.10.14 09:45
	Оценка:

От:	CaptainFlint	http://flint-inc.ru/
Дата:	16.10.14 10:00
Оценка:	+1