Possible to use svn as file system in rails application ?

[Muruga Raj]

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 )

Is it possible? I am completely blank on this.

Please help me in finding a solution.
Any of your suggestion will be very useful to me.

Please suggest

Thank you

 

[Marnen Laibow-Koser]

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.

Is it possible? I am completely blank on this.

Please help me in finding a solution.
Any of your suggestion will be very useful to me.

It should be possible. For Git-based solutions, you might get ideas
from ticgit or git-wiki.

Please suggest

Thank you

Best,

 

[Jordi Bunster]

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 )

Not that I think it's a good idea, but subversion can be installed in a
mode where it exposes a WebDAV volume, and when you save files,
they are versioned automatically.

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.webdav.autoversioning

 

[Florian Gilcher]

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.

 

[Marnen Laibow-Koser]

Can you please elaborate why a decentralized approach is required here?

I didn't know about SVN's autoversioned WebDAV, so I was thinking that
SVN would require both a repository and a working copy in different
places, whereas Git's decentralized model can keep it all together.

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]

Actually, I think it's a purely decentralized model, for the reasons
above.

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]

Possibly. I'm not sure how .git is organized.

[...].

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)

It seems to me that they can.

Also, they are not build for heavy concurrent(!) writing.

Aren't they?

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.

Isn't that sort of what versioned WebDAV does?

If you need metadata for the files: use a database-backed approach with
file system storage.

Isn't that what Git and SVN both do?

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.

True. But this is not straight backup.

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

That's clever.

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

Don't restrict the use of version-control systems because some people
call them source control.

Seriously, I doubt that either Git or SVN is really the right tool for
the job here. But I'm not certain.

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.

That was not what I did.

[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.

Best,

 

[Rick DeNatale]

Subversion would be a very poor solution here. =A0You will have better
luck with a decentralized version control system such as Git (and the
Grit library, perhaps). =A0Acts_as_versioned may also be worth looking a=

t.

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 sufficien= t
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.

--=20
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

 

[Florian Gilcher]

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?

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'.

--snip a long explanation--

I do know how git works. I question that it is a good system for that
use-case.
It might be possible to build something around the way git works, but
that
would require good knowledge of git internals Out of the box? I don't
think so.

Regards,
Florian