Управление конфигурацией с помощью Subversion и справки SharePoint

Question

Хорошо, когда год назад меня наняли в мою нынешнюю компанию, мне было поручено перевести наши команды разработчиков из VSS. Они уже думали, что хотят Subversion, и, поскольку у меня был опыт использования и настройки Subversion, я был хорошим кандидатом. Сначала я попытался продать TFS, потому что это решило проблему, в которой я сейчас нахожусь, но поскольку денег мало, а Subversion бесплатна ... ну, вы поняли. Как бы то ни было, я завершил раскладку, и единственное, что стоит на пути, это следующее.

Я предложил хранить только наш исходный код в SVN, а всю документацию, сборки релизов и другие артефакты проекта хранить на нашем портале SharePoint, поэтому нам не нужно предоставлять сторонним разработчикам доступ к SVN. Когда я представил предложение, все было исключено, но возник вопрос о том, как управлять синхронизацией между артефактами (напр., Как документ x версия 3.1.2 связан с выпуском 4.5.2). Моя первоначальная реакция заключается в создании на каждой странице выпуска SharePoint раздела для каждой новой версии, в котором будут храниться описания (и также будут отслеживаться изменения). Есть ли лучший способ сделать это? Кто-нибудь знает, кто-нибудь делает это? Или какие-либо пакеты интеграции для синхронизации SVN с SharePoint?

Вот некоторая информация о среде разработки компаний. Все наше программное обеспечение предназначено для внутреннего использования, мы не продаем его, поэтому все наши клиенты работают внутри компании. У нас есть два типа разработчиков: 1. те, кто заботится о поддержке и настройке стороннего программного обеспечения, и 2. те, кто пишет проприатрическое программное обеспечение (именно там я и попадаю). Наше программное обеспечение, которое мы пишем, в основном .NET, но стороннее программное обеспечение есть на всех платах (COBAL, C, FORTRAN, Прочая ерунда, о которой больше никто не заботится).

Пожалуйста, сообщите, так как мне нужно получить это в ближайшее время. Я ненавижу VSS !!!!!!!!!! и мне нужно облегчение!

Answer 1

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

В вашем случае, используя SVN, почему бы вам не поместить все внутрь, а затем использовать веб-интерфейс для предоставления доступа заинтересованным сторонам? Это достаточно просто для них: -P

Answer 2

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

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

Answer 3

Этот ответ, вероятно, слишком поздно для вашей реализации, но простейшим путем интеграции может быть сохранение документов в SVN и их последующая публикация в Sharepoint с помощью svn-hook.

Артефакты сборки могут быть опубликованы программным способом так же, как и сценарии сборки.

Вы можете загрузить документы в SharePoint с помощью простого POST

т.е.

http://blogs.msdn.com/rohitpuri/archive/2007/04/10/upload-download-file-to-from-wss-document-library-using-dav.aspx

Answer 4

В нашей организации мы имеем документы / артефакты, кодируем все в SVN и предоставили доступ нетехническим заинтересованным сторонам, а также тем, кто использует клиент черепахи.

однако вы можете посмотреть на следующую опцию

• Вариант 1: создать интерфейс ASP.Net для нетехнических пользователей

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

• Вариант 2: конечно, создать отдельных пользователей для каждого участника, не являющегося разработчиком

Answer 5

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

Answer 6

Я бы использовал SVN как для документов, так и для исходного кода.

Преимущества:

• Вы можете синхронизировать версии документы с версиями источника Код.
• У вас все в одном месте, поэтому нет двух хранилищ для администрирования.

Недостатки:

• Вам, вероятно, нужно управлять права доступа для некоторых заинтересованных сторон в некоторые части папки структур.
• SVN не самый подходящий инструмент для управления документами

Чтобы решить возможные одновременные изменения в одном и том же документе, вы можете использовать свойство SVN svn: needs-lock для этих элементов, чтобы их мог редактировать один человек, который блокирует элемент.

Как сказал Пабло, вы можете получить доступ к документам (хотя бы для их чтения) через веб-интерфейс.