On Nov 6, 2009, at 6:14 PM, Marnen Laibow-Koser wrote:

> Muruga Raj wrote:
>> Hello All,
>>
>> In my rails application users can upload the files. At present i am
>> using the file system as storage.( I don't use any of the plugin  
>> such as
>> acts_as_attachment or attachment_fu)
>>
>> My new requirement is to use "svn" for file storage. Because i need  
>> to
>> do the version control for user uploaded files.( Also i guess, if i  
>> use
>> svn it will reduce the storage space also )
>>
>
> Subversion would be a very poor solution here.  You will have better
> luck with a decentralized version control system such as Git (and the
> Grit library, perhaps).  Acts_as_versioned may also be worth looking  
> at.

Can you please elaborate why a decentralized approach is required here?
It is a purely centralized model and SVN actually does a decent job at
versioning binary files. Actually, in that case, even CVS has a  
sufficient
model, because I expect there is no interdependence between the files. 
[1]
So how is GIT superior to SVN in that case?
Is it even possible for git to return a specific version of a file  
without
having to check it out somewhere on the file system and then deliver it
to the client?[2] Because that would mean that there would be all  
kinds of
concurrent situations that you need to take care of. Then again, I'm not
a complete expert in git.

As I expect we are talking about binary files, neither of those systems
gives you an additional benefit.

Using a source(!) control system to version files in such a way is a bad
choice anyways. They are not meant for this use case and it will be a
pain to work with this in any case. Speed, revision schemes and the  
chance
that files are lost if parts of the repository get corrupted come to  
mind.
For example, neither the revision scheme of GIT or Subversion fits to
"per-file-tracking". Both cannot (easily) answer the question about the
"natural" revision of the file. (independent of other files)
Also, they are not build for heavy concurrent(!) writing.

Use a file system for binary file storage (that's what they are there  
for).
If you need a versioning scheme (which would probably be per file):  
use file
system storage with a versioning scheme baked into the directory  
structure.
If you need metadata for the files: use a database-backed approach with
file system storage.
If you choose the correct file system, backing up is as easy as git  
would
make it and a lot of backup-solutions are already around.

CouchDB might also be an idea to use for that.[3]

Don't abuse source control systems just because they usually carry  
"version"
in their names!

Regards,
Florian

P.S.: And don't reply with "git" if someone says "svn" without giving it
a long thought. Both are bad in that case.

[1] Not that I recommend it, though. But you could even argue that CVS  
model
fits better.
[2] This is in no way a criticism, it just doesn't fit git's model.
[3] They don't provide versioning for that use-case out of the box,  
but it is
really easy to implement.