Hi,
While I fully agree with Stefan, I would like to mention that we use svn in a non-standard way. We think still with very good performance and use case coverage. It is not for source code. It is technical sales project management. Sharing all kind of doks jpegs,mp3,mp4,pdf,word,... We successfully have ~3.000.000 Files in our repository. ~250 (commiters) ~1500 read only users since 2008.
We use tortoisesvn for most use cases. In addition to standard svn functionality, we created an SOLR based application for PowerPoint slide search and full text search.
The reasons to decide were:
a) SVN provides versioning (hey I am able to recover my presentation)
b) provides Path based authorization with Active Directory integration (as a large company we have to care about ip)
c) simple ui (tortoise) (even Sales can use it ;-))
d) checkout/check-in for offline usage is simple... (Good on customer site where we have no access to network)
e) Very good storage and network efficiency. (Good for home office/Hotel guys)
f) stable and reliable (we can use it 24/7 99% of the time)
g) active community (we can ask someone for help - and get it fast)
h) free and open source :-) - no compliance issues
i) multisite is supported, several multisite solutions exist. But keep in mind svn is not a distributed scm tool. (we thought we might need it, but actually not implemented it, just for speed of recovery we have a 2nd server that mirrors the data)
j) updates were smooth we started with svn 1.3 - and are now on 1.9 (no big invest in upgrades ... my boss is happy)
SVN was the tool that fitted best the needs of our project teams. And even better we have 2 part time admin (~10% of the effective Time) for the system.
However,
Svn has some "weaknesses' you should be aware of. OOTB it is not trivial/fast to query a file by properties like in Typical DMS. Backing up such large repositories through a dump is not feasible. Other means like btrfs/lvm2 should be put in place. SVN OOTB does not provide persistent encryption. You could encrypt during a commit by 3rd party tools. Transport encryption (https) is supported. And finally I would like to add that svn is not a file system, despite the fact that svn provides webdav capabilities. As Stefan stated, it is a scm tool :-) and it does the job really well.
Regards
Thomas
-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Donnerstag, 18. August 2016 09:46
To: Adam Jensen <hanzer_at_riseup.net>
Cc: users_at_subversion.apache.org
Subject: Re: A couple thousand mp3 files (this is not spam <honest> I swear </honest>)
On Wed, Aug 17, 2016 at 09:09:27PM -0400, Adam Jensen wrote:
> What I need (and what I think is generally needed) is a high-capacity,
> large-file repository with a focus on data integrity (mandatory audit
> trails), sophisticated access control (smart contracts (maybe
> blockchain based)), probably (almost certainly) an encrypted
> file-system, and distribution/replication (that is maybe torrent
> based). Files in this type of system might need to be deleted but they wouldn't be revised.
> This would not be a revision management system.
>
> I'm not sure how much of Subversion could be used/leveraged to build
> such a system.
Indeed it won't. I believe you should use something else for this job.
Not tracking changes contradicts a core requirement SVN was built for.
> At a minimum, it seems like it would involve a project fork and
> serious gutting and refactoring of the code-base after rethinking the
> basic principles, specifying the new requirements, and devising the
> new architecture. (And definitely a name change <smirk>).
You're free to use our code in whatever way you wish.
And we're always open to patches, of course.
But keep in mind that the code base is 16 years old and widely deployed.
Adding new features was easy in the early stages of development but is getting increasingly hard because of growing complexity and very strict reliability requirements imposed by our user base.
And we can't sever our roots:
"""
Apache Subversion is a full-featured version control system originally designed to be a better CVS. Subversion has since expanded beyond its original goal of replacing CVS, but its basic model, design, and interface remain heavily influenced by that goal. Even today, Subversion should still feel very familiar to CVS users.
"""
http://subversion.apache.org/features.html
So if you're really going to write a new piece of software for this you'll be much happier starting a new project from scratch rather than using SVN as a base.
-----------------
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 84564
Received on 2016-08-18 17:07:06 CEST