On 08/17/2016 04:36 PM, Johan Corveleyn wrote: > On Wed, Aug 17, 2016 at 9:13 PM, Adam Jensen <han...@riseup.net> wrote: [snip] >> So basically, the checkout method will require twice (2x) the data-set >> size of storage space for a working copy but there would be >> significantly less network load during many of the branch switches. The >> export method pretty much has the opposite storage/network trade-off. > > I guess you'd need this (very old) feature request to be implemented: > > https://issues.apache.org/jira/browse/SVN-525 (allow working copies > without text-base/)
Nice reference, thanks! Wow, that feature was requested during 2001. 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. 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>). It's not the Pyramid of Khufu big, or the Panama Canal big, but it would be a big project. For now, I still think I can use Subversion as the file repository in a limited capability, ad-hoc implementation of a small demonstration-of-concept instrumentation and analysis system.