Могу посоветовать еще проверенную временем классику: Hyperionics HyperCAM.

Например, можно одну стабильную версию сделать транком, а все последующие тестовые версии - копировать (бранчами). А ежели простой импорт всех версий - это будет совсем не то?

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

Внимательнее - как и описано в исходных данных, мы заказываем ПО у разработчика. Разработчик передаёт нам ПО, а мы его тестируем. Ведь не будем же мы принимать бажную версию, которая не работает. Поэтому исходников нет и не будет никогда. Вот и возникает такая задача - приёмочное тестирование переданных версий. Версии настраиваются конфигурационными файлами.

Alfa - совершенно верно, не ошибаетесь - не имею никакого опыта ;-) Хотя вполне представляю как работать с контролем версий при использовании исходных файлов (кода) ПО. А вот с готовыми версиями возник затор. Всё, что есть в настоящий момент - куча папок с тестовыми сборками. И когда происходят изменения в когфигах релизной версии, приходится всё переносить в тестовые вручную.

Поставил SVN. Поставил TortoiseSVN. Создал репу, импортировал несколько версий. Вот что примерно получилось:


Пояснения:
Версии папки Dev - тестируемые. Есть базовая версия, есть отдельная сборка (например, для Яндекса)
Версии папки Stable - стабильные. Опять же - есть базовая версия, есть отдельная для кого-то (тут - для Рамблера)

Смотрите - я вношу изменения в любой конфигурационный файл стабильной 1.28. Надо эти же изменения распихать и по тестовым сборкам папки Dev. Вручную - много времени занимает.

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

DrVal - вот смотрите, моделируем ситуацию: есть тестовая версия 1.5 продукта. Эта версия собирается (вручную, не разработчиком) в виде трёх разных сборок, которые необходимо протестировать. А есть версия 1.0 продукта и к ней выпускаются апдейты (в основном в виде изменяющихся xmlок). Так вот задача еще в том, чтобы из 1.0 эти изменения попали и в тестовые версии. Ну и, в случае принятия версии, из тестовых 1.5 изменения пошли в стабильную 1.5.

SVN сможет это обеспечить? И вообще, интересно, какие тулзы могут быть использованы тут?

Добрый день всем!

Сам я не тестировщик ПО ни в коей мере, однако, в силу работы, приходится заниматься тестированием готового ПО, так что скоро можно уже будет полноправно причислить себя и к тестировщикам ПО ;-)

Проблема вот в чём:
1. Имеется готовый Продукт - программа с полным набором экзешников, длллек, хелпов, конфигурационников и всего остального-прочего
2. Фирма-исполнитель (Разработчики) постоянно выпускают новые версии продукта, разрабатываемого по нашему заказу.
3. Естественно, что пользоваться тем, что выпускают разработчики никто не будет - необходимо протестировать полученное ПО
4. Существует несколько тестовых конфигураций Продукта для выполнения различных задач (и разные конфигурационники); существует несколько стабильных версий Продукта, для которого выпускаются обновления конфигурации самим Заказчиком.

Задача:
1. Увязать тестовые версии в различных сборках и конфигурациях и стабильные версии в конфигурациях, использовать некоторую систему контроля версий.
2. В конечном счёте - изменения со стабильных версий должны попадать и в тестовые

Только во проблема в том, что большинство систем контроля версий - для разработчиков ПО, работают на уровне исходного кода. Как же тогда организовать систему контроля версий для уже готового проекта? Мерджить конфиги, дллки, хелпа и прочее?

Быть может, кто-нибудь имел дело с этим? Был бы признателен за любую помощь по вопросу.