Лучшее решение для управления версиями для среды Oracle/ASP.NET?

Я пытаюсь запланировать возможность 5 разработчиков использовать Visual Studio 2005/2008 для совместной разработки веб-приложения ASP.NET на веб-сервере разработки против базы данных Oracle 8i (скоро будет 10 г).

Разработчики находятся либо в локальной сети, либо входят через vpn (не очень быстрое соединение),

Я оценил последнее Visual SourceSafe, но столкнулся с следующими ошибками:

1) Мы не можем использовать децентрализованное развитие, потому что мы не можем реплицировать базу данных ораков развития на все компьютеры разработчиков. Кроме того, vpn слишком медленный, чтобы локальные экземпляры приложений подключались к серверу базы данных.

2) Поскольку исходный код VSS не относится к файловой системе, единственный способ отлаживать его - это создать приложение и запустить отладчик, который только один разработчик может делать одновременно на сервере централизованной разработки. Это неприемлемо. Мы попытались использовать теневые папки, чтобы каждый раз, когда файл был проверен, он публикуется в экземпляре приложения на сервере разработки, но это не удалось для удаленных разработчиков на vpn.

3) Так как разработчики делают много веб-кода, важно по соображениям производительности, что, когда они СОХРАНИТЬ файл, они должны иметь возможность сразу увидеть изменения, работающие на сервере разработки.

4) Нет простого способа реализовать контролируемый процесс для перенаправления файлов на рабочий сервер.

Любые предложения по решению управления версиями, которые будут работать под этими ограничениями?

Обновление: Я предполагаю, что, поскольку разработка вынуждена находиться на сервере, нам нужно перейти с моделью "Блокировка и проверка". Итак, какое решение для управления версиями будет работать лучше всего для сценариев "Блокировка и проверка"?

Обновление: Поддерживает ли поддержка Visual SVN централизованно против сервера разработки? Как и в случае, разработчик может сразу увидеть его обновление на сервере разработки после сохранения в VS?

6 ответов

Я использовал Subversion и TortoiseSVN и был очень доволен.


Является ли точка 1 из-за проблемы с вашей схемой базы данных (или данными)?

  • Мы не можем использовать децентрализованное развитие, потому что мы не можем реплицировать базу данных оракула разработки на все компьютеры разработчиков.

Если нет, я настоятельно рекомендую, чтобы каждый разработчик имел свою собственную среду (Visual Studio, Oracle...) и использовал ваш сервер разработки для интеграции. Возможно, вы могли бы просто дать им подмножество данных или, может быть, просто сценарии схемы.

Прошу прощения, если вы уже представляли эти решения и считали их непригодными для своей ситуации, но я действительно почувствовал желание выразить их на всякий случай...


Visual Source Safe - это икру сатаны.

Посмотрите на Subversion и Visual SVN (с помощью Tortise SVN). Конечно, Visual SVN стоит немного - 49 долларов за место, но это отличный инструмент. У нас есть команда разработчиков из 6 программистов, и это было большим благом для нас.


Если вы можете потратить деньги, тогда Team Foundation Server лучше всего работает в среде разработки Visual Studio.

И на основе личного опыта он прекрасно работает над VPN-соединениями. И вы, конечно, можете сделать автоматические сборки.


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

VSS - это тип управления "блокировка и проверка", в то время как SVN и TFS, а большинство других - "редактирование и слияние" - разработчики получают все копии источника, при необходимости редактируют файлы и затем объединяют их изменения в исходном управлении, и если кто-то еще редактировал файл, тем временем они объединяют изменения вместе.

С точки зрения базы данных, я предполагаю, что вы проверяете свои сценарии базы данных, затем создаете автоматическую сборку и запускаете их (или, может быть, просто dev или DBA запускаете их вручную так часто). В этом случае наличие у разработчиков локальной копии сценариев, которые они могут редактировать и объединять с использованием SVN или TFS, имеет смысл.

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


Я бы сказал, SVN по цене (бесплатно), Perforce по простоте интеграции.

Вы, несомненно, узнаете о GIT и CVS, и есть веские причины смотреть на них.

licensed under cc by-sa 3.0 with attribution.