Can svn be used for documents?

We need documents shared by clients (CRM-like functions). Users should be able to:

  • Edit documents and save them again
  • Attach new documents

Our application is encoded in WPF with WCF for data transfer and NHibernate / SQL for data on the server.

what we think is to use SVN and force the application to create a local check of parts of the repository (when they click on a document, it is checked by SVN in the background and opens from the local path) - When saved, it will be silent (using path tracking) passed to the repository.

Question: Is this possible - or are there better solutions for this?

EDIT 1: Summary:

  • I will consider using Git / Mercurial instead of SVN
  • Document (revision) size may be prohibitive while waiting for tests
  • SharePoint is an option (although it is not viable in my case, since the cost itself is prohibitive). I will consider alternatives to SharePoint, tho.
  • Not much experience using repositories for many users, although it works for small teams.
  • Wiki software can be an alternative to SVN.

Thanks for all the reviews - I will continue to open it a little longer.

EDIT 2: Summary after several days of work - I have a client working - see My progress here .

+4
source share
6 answers

It depends on the type of documents you use. If you have many changes, compressed binaries, then do not use it.

However, if the documents are in an open format , such as Wiki, (X) HTML, LaTeX or uncompressed ODF, then using a version control system makes sense. In addition, a package of compressed ODF files or PDF files handles very well, especially if the files are mostly less than 5 MB or so.

Also, before sticking to the conceptually obsolete SVN, be sure to check out some more modern version control systems, such as Mercurial and Git . In your scenario, you will not profit from the "distributed" part of Mercurial and Git, but nevertheless they are easier to configure - at least in my experience. And they provide very advanced version control features that can save your day on rare occasions when you need them.

If you adhere to SVN, and if your client software runs on a modern Unix system, you can also try SVN-FS . This is a file system using a remote SVN server. Each reading goes to the latest edition. Each record creates a new commit. This is similar to what you wanted to build around SVN.

+1
source

Based on heavy .NET links, are you all set up using MSDN? Perhaps you can use SharePoint ... which may already be included in your MSDN account.

+3
source

You can also consider using Wiki for document management - I have seen this and am doing it myself for my own organization. We use the Atlassian Confluence Wiki. Confluence provides version control and general document management.

+3
source

I would not use SVN for this, SVN is not very effective when working with binary files. Using SVN as the return channel for some content in your application, you simply complicate the situation by adding other technology and dependency, but you will not use most of your real potential.

I would like to store documents as blocks in a database and receive / store them through WCF.

+2
source

As a rule, I don’t think that SVN or any version control system is a good thing for document sharing. The main drawback is the diff system in binary files ... Your SVN repo will grow rapidly.

Maybe you should try using some commercial tools designed for sharing documents (for example, Microsoft Sharepoint). Or some open source alternatives ... Maybe you should read this post ...

+2
source

I think using ready-made and proven technologies is a great idea. I would like it to progress if you really go this way.

I would strongly go against SharePoint - you will tie yourself to Microsoft in manners that are hard to describe here. From my point of view, SharePoint is a technology that should only take care of itself.

+1
source

All Articles