On Sat, Nov 7, 2009 at 12:39 PM, Florian Gilcher <flo / andersground.net> wrote:
>
> 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.  ¨Βου χιμμ θαφε βεττες
>> luck with a decentralized version control system such as Git (and the
>> Grit library, perhaps).  ¨Βγτσίασίφεςσιοξεδ νααμσο βε χοςτμοολιξατ>
> 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?

I don't think the real advantage of git is that it's a distributed
model, but rather that it's a version control system built on what is
effectively a history tracking 'file system'.

The git implementation is very good at representing a file system as a
series of trees which vary over time, with stuff in successive
versions of the tree (or in some cases even non-successive versions)
stored ONCE.  Basically the way git works is a kind of
content-addressible store, where the actual files are named with their
SHA-1 hash, so that two files with the same contents will have the
same name.  And directories are just text files with the same SHA-1
naming scheme, containing the names, attributes, and SHA-1 pointers to
the files and subdirectories they contain.

Now this is a good feature for a distributed system, because files (or
blobs as git calls them) with identical contents always have the same
name no matter what machine they originated on, which makes synching
the contents of repositories dead simple, but it's not being
distributed which leads to the design of git's storage model, so much
as that the storage model makes distribution easier.

SVN and other more 'traditional' systems store commits as either a set
of diffs between the old state and the new, or as reverse diffs
between the new and old states, and reconstruct most of the files on
demand by applying the right series of 'patch/diffs'.  This is time
consuming, causes difficulties in dealing with binary files (which
don't diff nicely so need workarounds), and turns out to be less space
efficient in almost all real-world cases.

I can't recall the actual numbers, but I'm quite certain that, for
example, when Rails moved from SVN to Git, the file storage needed to
keep the entire project history was MUCH smaller.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale