Have you looked at Sharepoint which is basically what you are describing?
RedWolves
2009-01-26 20:13:08
+1
A:
<ul><li>This needs to fit nicely into our automated deployments.</li><li>we need to be able to run the application on our local developer machines, without needing a connection to a separate server</li><li>we would like something light weight, and easy to upgrade</li></ul>
mr mo
2009-01-26 20:16:49
You need to put a lot more information with what part you are specifically having trouble with in your question then.
Geoffrey Chetwood
2009-01-26 20:19:44
A:
Why not just use subversion with one of the many clients that might suit your needs out of the box?
Geoffrey Chetwood
2009-01-26 20:14:30
We need to ensure that our domain model can still control what documents each user is able to see. We want users to still use the same web interface that they have been using with our existing system.
mr mo
2009-01-26 20:43:44
+3
A:
Subversion does sound like the best bet here, just train the users that have to manage the documents in how to use TortoiseSVN and then have your document storage be a sub directory of your project.
Josh W.
2009-01-26 20:26:34
We need to serve these documents over the web through an existing application, that requires clients to be logged in. We also need to restrict what documents users can see and edit. Can you do this with TortoiseSVN as a client?
mr mo
2009-01-26 20:44:58
@mr mo: With the exception of going through a browser, yes. Have you looked at tortoisesvn yet before rejecting it?
Geoffrey Chetwood
2009-01-26 20:49:49
This doesn't sound like the way to go - if you're looking to server documents through a browser and manage upload through a browser then TortoiseSVN isn't going to give you this.
Nick Pierpoint
2009-01-28 16:14:40
A:
If you are building it yourself and using C# and SVN then sharpSVN looks like a good solution. With full access to the SVN Client API you should be able to happily be able to integrate the web application to a SVN backend. Enforcing security by SVN properties or some other meta data store.
Some of the problems I can see are:
- you that if you have multiple sites it maybe hard to get different SVN Repos to play nice when they have to sync up (if they have to).
- SVN doesn't do much more than store binary blobs, so it will only version the objects, and not be able to give you diffs of them. This may lead to a very large SVN database.
- It is also currently not possible to purge a file from a repo, which will also lead to large SVN repos.
- If different people can revise documents, and expect them to be different "branches" of the document, then it may be better to use a distributed source control model where such things are easier.
Andrew Cox
2009-01-26 22:09:21
A:
Although it would be nice to re-use something like Subversion on the server, it does make application roll-out more complicated. If you're happy with this then sharpSVN (as suggested by Andrew Cox) seems like a good fit.
If you're less worried about some of the version control aspects of Subversion (diffs and branches) then I'd be tempted to knock together a quick document management module to your existing application.
I would use Lucene to handle the tricky stuff - indexing and full text search.
Nick Pierpoint
2009-01-28 17:38:32
A:
If I were you I would investigate Sharepoint, or at least Sharepoint Portal services. This is precisely the scenario the solution addresses
Conrad
2009-01-28 17:42:19
A:
We opted to build our own domain model, and store documents in a SQL Server 2008 database. So far this has worked great for us.
mr mo
2009-02-28 01:16:15