On 08/17/2016 04:36 PM, Johan Corveleyn wrote:
> On Wed, Aug 17, 2016 at 9:13 PM, Adam Jensen <hanzer_at_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.
Received on 2016-08-18 03:09:42 CEST