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.
Received on 2016-08-18 09:46:32 CEST