WebSharperвы создаете ветку на каждую фичу?
Нет, зачем так часто?

Alexey TominДа, сложно объяснить чем git лучше SVN. Но это реально намного удобнее.
Вот это "сложно" намекает на то, что вы и сами не поняли, зачем оно вам.

WebSharperЕсли вы их не создаёте в системе контроля версий, то логически они у вас есть, но вы не пользуетесь возможностями СКВ чтобы ими управлять.
Что конкретно становится неуправляемым? Что конкретно я с этого теряю? На мой взгляд я приобретаю время, сэкономленное на создании ветки из-за дополнительной формочки для клиента. И уменьшаю общую сложность, что как раз повышает управляемость. А вы каким макаром повышая сложность чего-то там добиваетесь?
WebSharperВы уже вверху сказали что у вас за локальную историю отвечает эклипс.
Это к чему вообще?
WebSharperТак же есть задачи бекапа, мерджа с новыми изменениями и прочее.
Ну задачи есть разные. И что, я обязан все задачи исключительно через SVN прогонять? Бэкап в SVN уже автоматом есть, что я ещё с ним должен делать? Мержит народ вполне самостоятельно и меня по этому вопросу не беспокоит, что опять я эдакое упустил, что бы было много лучше (примерно как у вас)?

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

SiemarglПро SVN скажу минус - нет полноценных отдельных визуальных утилит.
Возможно. Хотя Эклипс на столько распространена, что я бы сказал - для Java такой проблемы нет. Ну и на других языках оно тоже работает. А если кто-то использует альтернативную IDE, то в ней наверняка есть поддержка минимальной локальной истории и неких расширений для работы с SVN (хотя тут, конечно, за всех сказать не могу).

WebSharperсоздание ветки - это одна команда ... Это очень быстро и не дорого.
Мусор тоже можно легко создать. Но зачем?

То есть это не аргумент.
WebSharperУ вас управлением версиями занимается два инструмента - эклипс для локальных изменений и svn для общих. Два инструмента со своими возможностями вместо одного для одной и той же концептуально задачи - хранения версий - это, по-моему, сложнее.
Каждый инструмент в данном случае адаптирован под свои задачи. Я могу скопировать весь прожект и работать с ним вообще без "контактов с центром", при этом у меня локально ведётся история и я могу по ней много чего делать. То же самое с полностью независимым прожектом (типа личная писанина). То есть вменяемая IDE (Eclipse) даёт одинаковые возможности хоть для индивидуалов, хоть для команды. Переход от одного вида разработки к другому просто элементарен - подключаем SVN и тягаем оттуда прожект - всё, далее просто работаем.

В случае с git-ом в обоих случаях (индивидуально/командно) нужно возиться с оной приблудой. В случае эклипсины для инди такого вообще не надо, что сложность как раз понижает.
WebSharperЕсли использовать бранчи для фич, то просто тем же инструментом можно делать те же операции что локально, что в общем репозитории.
Зачем делать что-то обязательно через общий репозиторий?

Еще раз повторю поток действий - разраб пилит сколько хочет в IDE, в ней же он все свои фичи/бранчи как ему нравится ваяет средствами самой IDE. Когда он наконец наигрался - делает мердж. К определённому моменту все, кто успел, мержат и далее прогоняются тесты с раздачей пряников. Если нужно откатить неудачное чьё-то решение - выдираем его по дате из SVN. Если нужно создать версию - создаём и группа разрабов уже портит не общий код, но именно версию (ну или бранч, если кому-то это нравится).

В целом никто нигде не спотыкается, всё работает плавно и летит только вперёд.
WebSharperВот вы делаете фичу. Она состоит из некоторых элементарных измнений. В процессе работы, пока вы не отправите ее в репозиорий, SVN о ней ничего не знает и не может ее забекапить. Если делать фичабранч, то можно в процессе работы после каждого элементарного изменения его комитить в бранч и будет и бекап и детальная история.
Ну здесь проблема из серии "раз в несколько лет накрылся диск". Раз в несколько лет переделать труды за один день - никакой проблемы не вижу. А вот добавлять тулзу, которую нужно дополнительно ласкать каждый божий день - ну её такую требовательную подальше.
WebSharperНеплохо бы подлить к себе его изменения и посмотреть, как это работает вместе
Ну как бы просто делим народ на группы, а в пределах группы стараемся разделять взаимное влияние (между группами вообще влияние минимально). А если что-то обязательно нужно совместно - коммитим до тестов и балуемся, а потом ещё тестами накрываем. Ну и если всё так плохо, что в отведённое для устранения косяков время "не шмогла", то вырезаем чьи-то изменения. Но это уже редкость.

И даже я могу себе представить, что потенциально возможна какая-то тулза, которая сделает работу ещё удобнее, но просто это повышение удобства даст (условно) хорошо если пару процентов к общей производительности, а то ведь и вообще даже процента не даст. Но для получения такого прямо скажем - убогого - результата, нужно всех напрягать на пару недель переучиваться на новую тулзу с потерей производительности и прочими косяками. Цена не оправдывается. Хотя я вообще за то, что бы выделять время на "боевое" тестирование новых технологий (не на юзерах, конечно, но в приближённых к реальности условиях), только здесь ещё нужно выбить финансирование таких забав, что совсем непросто.

skyANAА зачем выдирать неудачное решение вместо того, чтобы не пропускать его?
Потому что не всегда просто выяснить на сколько всё запущено. И тесты не помогают в сложных случаях.
skyANAАвтоматическая сборка, автоматический прогон модульных, интеграционных, функциональных тестов перед тем как мёржить у вас отсутствует?
Я же написал - прогоняем тесты. Но сам девелопер если хочет может прогнать тесты на своей версии локально. И обычно небольшие компоненты перекрёстно опыляются писателем тестов и компонентов, а без общей работоспособности релиз не идёт. Если сроки жмут - вырезаем что-то. Но это редкость.
skyANAА какая у вас на данный момент производительность? Как часто выпускаете новые версии, сколько по времени занимает публикация?
Частота определяется потребностями. Задача = сделать такой-то функционал к такому-то сроку - вот от неё и танцуем.