OberonCore

Например, вот тут: Т. е. Вы старый код закомментарили не присвоив ему при этом номера версии, но это сути не меняет: "старый код" и "новый код" - это разные версии одного и того же кода!

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

Понятно. С многолетними проектами не работали, с изменением требований не встречались.
Тогда СКВ можно изобретать в комментах, да.Сделает. Именно для этого СКВ и созданы.

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

Вы не встречались? У меня это основная деятельность.

igor, я так реагирую, потому что вы не поняли о чем речь, и не хотите видимо понять. Дело ваше

Илья Ермаков только правильно меня понял

Вот в чем заключается ваше непонимание.

Правки делаются на той версии, в которой они обнаружены. Соответственно они переносятся уже без этих пометок на новую версию.

Новая версия появляется только тогда, когда ВЫ ЕЕ ОПУБЛИКУЕТЕ.

А внутри проекта вам не нужно ничего, кроме архива версий (с правками и логами конечно). Чем СКВ лучше?

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

То есть Вы храните в исходнике информацию только о последних изменениях, а не обо всей истории изменений?

Да. История изменений остается в логах. А правки в архивах

А в новом имени что? Номер версии?
Речь пока о линейной истории была, просто с пересечением границ правок. У меня модуль верхнего уровня реализует прикладную логику: иногда нужно сообщение показать ДО, иногда ПОСЛЕ, вот и двигаешь туда-сюда, пока пользователь не удовлетворится. На каждый чих не напасёшься модулей ; )
Ну да ладно. Тут уже речь о разных акцентах внутри процесса разработки. СКВ позволяет увидеть работу как набор изменений, а обычный подход акцентирует промежуточные результаты-достижения, вокруг которых всё устаканивается.

к вопросу о нужности сабжа:
какая-то скв интегрирована в редактор, если я не ошибаюсь, xcode для мака

Subversion или Git.

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

Ха!
Смотрел сейчас последнюю серию Хауса, и как раз заглядывал сюда: http://en.wikipedia.org/wiki/Compulsive_hoarding

Не поймите меня превратно. Как говорится, в каждой шутке есть доля шутки : )

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

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

Хочешь поэкспериментировать - подмени реализацию и копай себе сколько влезет.

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

Интересно, что я думал ровно о том же, но в обучающей системе:

Подобные совпадения говорят о том, что потребность назрела.

Проникновенно, спасибо за формулировки.