Configuration Management with Subversion and SharePoint help

Question

Ok, when hired on to my current company a year ago, I was tasked with migrating our development teams from VSS. They already had it in their minds that they wanted Subversion, and since I had experience using and setting up subversion, I was a good candidate. I first tried to sell TFS because it woul dhave solved the problem I am in right now, but since money is tight, and Subversion is free... well you get it. Anyway, I have finalized the propsal and the only thing standing in the way is the following.

I proposed that we store only our source code in SVN, and all documentation, release builds, and other project artifracts be stored in our SharePoint portal, so we don't have to give non developer stakeholders access to SVN. When I presented the proposal, all was excepted but the question arose about how to manage the syncronization between the artifacts (Ex: How to is document x version 3.1.2 associated with release 4.5.2). My initial reaction is to create a section in the SharePoint porject page for each new release that will hold the artificats (and keep track of changes too). Is there a better way of doing this? Does anyone know of anyone doing this? Or any integration packages to sync SVN with SharePoint?

Here is some info on the companies development environment. All of our software is for internal use, we sell none of it, so our customers are all in-house. We have 2 types of developers: 1. those who take care of maintainance and customization of third party software, and 2. those who write proprieatry software (which is where I fall). Our software we write is mostly .NET, but the 3rd party software is all over the board (COBAL, C, FORTRAN, Other crap that no ones cares about anymore).

Please advise, as I need to get this submitted soon. I HATE VSS!!!!!!!!!! and I need relief!

Answer 1

What we do internally is putting all docs under our version control system, I think it's much easier. Then, of course, you have to give access to not-developers.

In your case, using SVN, why don't you put everything inside and then use the webinterface to give access to the stakeholders? It's easy enough for them :-P

Answer 2

I would use SVN for both documents and source code.

Advantages:

• You can synchronize versions of documents with versions of source code.
• You have everything in one place, so no two repositories to administrate.

Disadvantages:

• You'd probably need to manage the access rights for some stakeholders to some parts of the folder structures.
• SVN is not the most appropriate tool for document management

In order to solve the possible concurrent changes to the same document, you can use SVN property svn:needs-lock for these items, to make them editable by one person, who locks the item.

As pablo said, you can access the documents (at least for reading them) through the web interface.

Answer 3

You could expose the svn repo via the web interface and link to that in sharepoint. That way people who need to edit the documents would need access to subversion but anyone could easily access the documents "read only".

Answer 4

In our organization, we have docs/artifacts, code everything in SVN and have given access to non-technical stakeholders as well who use tortoise client.

however you can look at the following option

• Option 1 : create a ASP.Net interface for non-technical users

You can build a simple web interface in ASP.net, configure that with a single user so you would not have to create separate users for all the nontechnical stakeholders and they would get access to the docs with proper version control, etc. you could look at sharpsvn for the implementation aspect. the disadvantage of this approach would be that you might have to invest some time in developing this app

• Option 2 : ofcourse, create separate users for each non-developer stakeholder

Answer 5

This answer is probably too late for you implementation, but the simplest integration path may be to store the docs in SVN and then publish to Sharepoint with an svn-hook.

Build artifacts could be programatically published the same way from you build scripts.

You can upload docs to SharePoint using a simple POST

i.e.

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

Answer 6

Probably a little late, too, but I would avoid putting the documents in SVN if you have a SharePoint system setup. Though SVN does a fantastic job for source code, for document management it doesn't provide the ease-of-use of SharePoint. If you have it already setup and you are a primarily MS based network, SharePoint makes a lot of sense and can handle revision control for the MS based documentation much better than SVN.

Yes, you can manage access to SVN documents with a needs-lock, but chances are at some point you'll have a non-developer needing to access the documents. Explaining SVN to a non-developer, non-techie is not an easy thing.