git-svn

Да, и еще, насколько оно безопасно? Не хочется попортить репозиторий в очень активной фазе разработки своими экспериментами.

Уговори их на SVN 1.5. Ну или попробуй SVK.

Мы сейчас на 1.5. Все равно жуткая хрень. Уже мерджинфо приходится руками править, чтоб хоть как-то мердж сработал.

А за свк спасибо, если гит-свн не сможет попробую его.

> Уже мерджинфо приходится руками править, чтоб хоть как-то мердж сработал.

Круто. Ну тогда тебе нечего терять :) Я, правда, не думаю, что двухстороннее преобразование в/из Git тебе поможет.

И по-любому, сначала поэкспериментируй на копии SVN-репозитория.

Я бы сказал, что git-svn в данном случае не поможет. Он хорош когда у тебя у самого много бранчей в git и ты какую-то из них или несколько периодически мержишь/коммитишь в svn варварам.

> Круто. Ну тогда тебе нечего терять :)

Ага. Теперь хочется посмотреть в глаза тем, кто в флеймах о хг и гите говорил, что в свн с мерджем все прекрасно.

> Теперь хочется посмотреть в глаза тем, кто в флеймах о хг и гите говорил, что в свн с мерджем все прекрасно.

Я не пользовался SVN 1.5, но думаю, что в ней с мержем всё более-менее нормально, а у вас просто запутанная система бранчей и, как следствие, путаные мержи. В Mercurial граф ревизий тоже можно запутать очень сильно (думаю, и в Git).

> ты какую-то из них или несколько периодически мержишь/коммитишь в svn варварам

более политкорректно говорить не "варварам", а "аборигенам" :-)

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

В меркуриал и гите запутать дерево можно, но оно в любом случае останется деревом.

Мержи облегчить может (всё-таки в гите автомерж поумнее будет чем в svn), однако, при обратном экспорте в svn никакой mergeinfo не экспортируется (и при импорте он тоже не используется). Соответственно, "аборигенам" на svn-е это может несколько осложнить жизнь.