svn использую больше года. В настоящее время стоит задача вести совместно проект на ucLinux. Работаю под Debian. Поставил eclipse и subclipse версии 1,6 под него. Пытался сделать checkout с репозитория на свой комп. Никак не получается. Мало того что в проекте очень много файлов, процесс идет очень медленно так еще и eclipse вылетает постоянно. Позднее решил сделать update того что не хватает в проекте с помощью консоли и других GUI под Debian. Оказалось что версии всех svn клиентов и консольного под Debian 1.5 и она не совместима с версией subclipse 1.6.
С git пробовал создать репозиторий и делать туда push (так вроде называется) но там ничего не обновляется.
Стоит ли осваивать git? Будет ли он работать быстрее чем svn. Или нет никакой разницы что использвать.

С большими и очень большими репозиториями git работает однозначно много быстрее чем Svn. Я лично уже давно перешел на git на работе и в своих домашних проектах. Мне он очень нравится. Но здесь есть разница не только в скорости работы и прочих ньюансах, а в идеалогии этих систем: Svn - централизованная, Git - распределённая. Для кого-то это имеет значение. Не всегда переход на git бывает лёгким именно по этой причине - git его надо понять.
PS.
push "затакивает" измененные объекты из локольной рабочей копии в удаленный репозиторий. А чтобы новые файлики попали в эту локальную рабочую копию, их туда надо добавить git add, потом сделать git commit. Как я понял вы это хотите сделать. Если-же удаленного репозитория нет, а только рабочая копия - достаточно просто git add и git commit.

Интересно, что такое большой репозиторий ? Посмотрите на этот: http://svn.freebsd.org/base/. Размер около 10ГБ, файлов - не счесть, ревизий более 200 тысяч. И ничего, работает вполне нормально. Поэтому проблема скорее всего в чем-то другом.

На счет того, что выбрать. Как уже сказал neiver, это две разные модели хранения веток разработки. В случае svn, если вам нужно надолго отпочковаться от базовой ветки вы просто создаете еще одну ветку и делаете в ней что хотите, при этом можно дать другим посмотреть на плоды вашего творчества. При этом все хранится на одном сервере, упрощается администрирование и бэкапы. В случае с git, репозиторий можно клонировать и работать с ним на локальной машине, но за хранение и доступ уже отвечаете вы сами.

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

Касательно версий: всегда использовали только официальные ветки/билды и не было никаких проблем. Естественно, для всех операций использовали только rapid-svn, командную строку или ее обертки из оболочек/редакторов.

В этом я вижу пока только минусы git. Мы выдем проект вдвоем. В случае с svn если возникают проблемы с компиляцией можно сделать update на предыдущую ревизию из репозитория и продолжать работать. А с git если я и коллега что-то попортим в своих исходниках то делать update неоткуда. Или git хранит историю изменений на каждой локальной копии и update делается со своего же компа?
У нас исходники весят около 1,5ГБ файлов около 60000. Значит svn с этим должен легко работать.
Похоже в eclipse+subclipse. Вчера для пробы сделал checkout из консоли в другой каталог, завершилась менее чем за час. На checkout из subclipse уже потрачено часов 5 и еще не завершено. Похоже стоит использовать rapid-svn, а в eclipse только редактировать код.

Да, именно так. Гит обычно хранит всю историю изменений в каждой копии препозитория. Но можно и сделать checkout только последней ревизи если надо. Причем все репозитории и рабочие копии главный рапозиторий(если такой имеется) впринципе равнозначны.

Это по локальной сети? Или через инернет канал мегабита в четыре?
У меня ~ 1 GB исходников. На работе по 100 мегабитной локальной сети репозиторий клонируется меньше чем за 10 мин. Из дома 4Mbit минут за 40.
Вся служебная информация(читай история изменений) занимает 170 Мб при 1Гб исходников и полутора годовой истории изменений.

Нету никаких минусов. Более того, на мой взгляд, у централизованных VCS нет никаких преимуществ перед децентрализованными. Имея копию репо у себя, вы не зависите от наличия соединения с севером. Например, захотелось вам сделать svn log или svn blame, а сервер c репо недоступен. Вот и аюшки.

С git можно работать так же, как и с svn: сделать центральный репо, с которым периодически синхронизироваться (git pull/git push).

Разумеется, любое изменение можно откатить. А за git bisect я бы авторам поставил памятник. Более того, работа с ветками в git гораздо более приятная (включая git rebase и git cherry-pick). git merge вообще сказка. Работа с отдельными коммитами тоже на высоте: git rebase -i позволяет изменить порядок коммитов, слить несколько коммитов в один, убрать ненужные.

Итого: имея опыт работы и с git, и c svn, я большого смысла в использованиии svn не вижу.

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

Для svn есть подобный аналог - svk. Удобно, когда едешь в тьмутараканьбезинтернета.

У обоих систем есть свои преимущества и недостатки. В git мне не нравится структура в виде сотни с лишним разнородных скриптов, предпочитаю более цельные продукты.

Извините, что влезаю в дискуссию, но подскажите достойную литературу по svn и по git. Мало что знаю про системы контроля версий, а разобраться хочется...

Официальная документация - самая достойная литература

Its a UNIX way.
А чем она эта структура не нравится? Все эти "скрипты" доступны из одной команды "git":
git init
git pull
git push
git rebase
...

А если хочется вида целостного продукта, то можно и графическую морду к нему поставить. Я вот GitExtensions пользуюсь. Удобная штука, рекомендую.

Выбор VCS очень ответственная задача, т.к. сбои в ее работе могут обернуться серьезными последствиями и простоями. Поэтому мне важно качество кода. Посмотрите на количество релизов git - более 160 за 5 лет, для subversion эта цифра в два раза меньше, но за 7 лет.

Ну, и то, что git таскает за собой весь репозиторий для меня является недостатком, т.к. нет возможности извлечь файлы/историю только для подпроекта. Насколько я знаю, это до сих пор не решено в полной мере, т.к. изначально git разрабатывался для монолитных проектов типа ядра Linux.

т.е. git сырой и там постоянно исправляют баги?

Не надо делать поспешных выводов. Также не надо сравнивать качество разных программ, считая число релизов. Это просто неправильно.
И SVN, и git - хорошие системы. Выбирать надо под задачу. Лично я использую SVN, так как мне нравится концептуальная простота этой системы, а её возможностей вполне хватает. Понадобятся продвинутые фичи из git - стану использовать, а пока мне не хочется забивать голову тем, что мне не нужно.

За два года использования Git ни одного его бага в нашей команде обнанужено не было. Наверное мы неправильно его использовали

Вы просто на них не нарывались, посмотрите на RelNotes-*. А что касается числа релизов, то попробуйте всех заставить обновлять всех клиентов с такой частотой. Hint: у нас разработчики сидят не только в одном здании, но и на разных континентах. Мы svn уже используем шесть лет, до этого был cvs, а еще раньше (страшно вспомнить) - rcs.

Аналогично. Разработчики на разных континентах. Раньше пытались (тоже страшно вспоминать) использовать ClearCase (земля ему пухом) ибо корпоративный стандарт. Ох и намучались с ним. Svn использовать не получилось из-за особенностей IT инфраструктуры зарубежных коллег, хотя изначально хотели использовать именно его, потому, что был опыт. Потом решили перейти на Git. Сначала, как эксперимент, поддерживали два репозитория, один в Git, второй в ClearCase, с автоматической синхронизацией. А потом, ClearCase сервер благополучно упал и никто его поднять больше не смог (а точнее настроить синхронизацию с буржуйским сервером), и это и стало его концом. И стал Git у нас основным сорц контролом, благо инфрастуктура уже была готова. Теперь два года как им пользуемся и проблем не знаем.

Не подкинет ли кто мануал по установке GIT сервера под винду? Нашел вот это http://www.timdavis.com.au/git/setting-up-...ssh-on-windows/ Но на этапе "After the text .bashrc file# (after the pound with a space) – paste in - export HOME=/c/SSH/home/<user> - i.e. in our case export HOME=/c/SSH/home/Administrator" тормознул. Нет у меня строчки .bashrc file# есть строчка # User dependent .bashrc file