>Нафиг на локалхосте поднимать древний линух с кучей специфичного мусора?
Вы драйвера для старых ядер разарабатываете?
Если нет, то непонятно - почему нельзя вести разработку на современном десктопе?

Сравни push/pull и svn merge с туевой хучей аргументов.

Зачем, если есть пара десятков программ, которые делают всё это не напрягаясь?

> непонятно - почему нельзя вести разработку на современном десктопе?

Потому что можно ненароком зацепить новые возможности; потому что старые возможности могли быть тупо удалены.

>Потому что можно ненароком зацепить новые возможности; потому что старые возможности могли быть тупо удалены.
Если это так критично легко поставить комию в ВМ доставить нужные компоненты.
Как бы то нибыло - не вижу разумного оправдания игногированию нормальных средств.

>>Потому что можно ненароком зацепить новые возможности; потому что старые возможности могли быть тупо удалены.

легко поставить комию в ВМ

Щито?

доставить нужные компоненты.

Их может тупо не быть.

>Щито?
сорри.
Копию в Виртуальную Машину

Как бы то нибыло - не вижу разумного оправдания игногированию нормальных средств.

Первая твоя умная мысль за весь тред.

Зачем, если есть пара десятков программ, которые делают всё это не напрягаясь?

Назови их! Причем, почему-то, эклипс не входит в их число, он мне так же радостно сносил коммиты при мердже. Не находишь, что количество неосиляторов svn merge превышает все разумные пределы? Тогда как в других vcs, эта примитивная операция и делается примитивно — одной командой, без фатальных последствий.

> Копию в Виртуальную Машину

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

Да, такой вариант имеет право на жизнь.

Однако практика показала, что сообщения об ошибках от хуков, даже если они написаны капсом и обрамлены кучей пустых строк и восклицательных знаков и понятны - их все равно не читают, а бегут жаловаться что нифига не работает ):

>> Как по мне, выбор svn для нового проекта - профнепригодность. Прям вопрос для собеседования на позицию тимлида - «Какие проблемы будут испытывать разработчики, используя svn вместо hg? hg вместо git?»

Окончание вопроса подразумевало, что git лучше hg. Или я вас неправильно понял?

А svn выберу, если потребуется соблюдать необходимые в компании процессы. У меня для svn целый фреймворк самописный по автоматизации кучи рутины во время коммита. Плюс свой модуль для svnserve, обучающий его работе с ldap с per-repo доступом на основе групп.

Кроме редакторов есть еще и компиляторы и другие тулзы, которые не всегда толерантно относятся к переводам строк. BSD pmake, например.

Ну и в корпоративной среде, знаете, не принято переставлять весь парк вынды сразу же с выходом новой версии (:

Откройте для себя http://www.orcaware.com/svn/wiki/Svnmerge.py

Мы уже несколько лет как для себя открыли. Теперь большей частью рутины по мерджу у нас занимается cron (:

Если нет, то непонятно - почему нельзя вести разработку на современном десктопе?

Можно, но для этого во-первых придется собирать 100500 3rdparty библиотек, которые в собранном виде есть только под продакшен систему. А во-вторых никто не гарантирует, что система будет функционировать на новом дистрибутиве _также_ как и на древнем.

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

Зачем, если есть пара десятков программ, которые делают всё это не напрягаясь?

Зачем мне пара десятков программ, если речь об svn ?

> Окончание вопроса подразумевало, что git лучше hg. Или я вас неправильно понял?
Вопрос корректен: «Какие проблемы будут испытывать разработчики используя hg вместо git?» Ответ - «никаких», ну почти :)

А svn выберу, если потребуется соблюдать необходимые в компании процессы.

В моем понимании «новый проект» не включал какую-то завязку на старую инфраструктуру. Понятно, что жрать легаси-кактусы - святая обязанность любого айтишника.

>Зачем мне пара десятков программ, если речь об svn ?
Я говорил о графических merge-tools

для vcs для нормальной работы нужны gui-шные костыли и подпорки, то в топку такую vcs

Т.е. hg и git в топку так как для них есть GUI утилиты?
А тем-же git из командной строки пользоваться может только Линус

> Причем, почему-то, эклипс не входит в их число, он мне так же радостно сносил коммиты при мердже.

Может, все VCS-плагины для Eclipse тупо неюзабельны? :)

в hg всё можно делать без графических утилит

А тем-же git из командной строки пользоваться может только Линус

Весьма голословно. С тех пор много что изменилось. К тому же — есть mercurial.

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

Насчет pmake хз, но более-менее популярные тулзы все умеют и «\r\n», и «\n».

Ну и в корпоративной среде, знаете, не принято переставлять весь парк вынды сразу же с выходом новой версии (:

Всё, кроме блокнота, давно умеет три варианта конца строк.

Объединю два Ваших высказывания. В них ода и та же ошибка.

Всё, кроме блокнота, давно умеет три варианта конца строк.

python, как и perl и bash, есть везде.

Это все так, если рассматривать систему в териминах «может» - «не может». Но это, что называется, не вся правда.
Следующий вопрос (после ответа «может») - с какой вероятностью мы огребем проблем в этой точке и сколько это будет стоит. «Может» не значит, что вероятность огрести - 0. И не надо пытаться сделать вид, что она 0. Надо честно считать риски.

Билдинженеры

читают эту тему и удовлетворенно ухмыляются - на их век работы еще много будет.

Спасибо разработчикам! SVN для меня - один из самых полезных продуктов в профессиональной деятельности.