On Wed, Aug 17, 2016 at 9:09 PM, Adam Jensen <hanzer_at_riseup.net> wrote:
> 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.
You are probably already aware of this, but on the server side, the
repository is essentially an opaque database. You will not see anything
resembling your files directly on the server filesystem. So unless you
build your own custom code that used the repository API layer you can only
interact with the content of your repository using a SVN client of some
kind.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2016-08-18 17:17:29 CEST