On Sat, Aug 13, 2016 at 3:29 PM, Adam Jensen <hanzer_at_riseup.net> wrote:
> On 08/13/2016 02:21 PM, David Chapman wrote:
>> On 8/13/2016 11:07 AM, Adam Jensen wrote:
>>> When a branch is created, are the files under revision control in the
>>> trunk copied to the branch (is there any duplication of files in the
>>> repository)?
>>
>> No, the files are not copied; a rename is stored. These are "cheap
>> copies", and this is an advantage over simple backups - if you want to
>> save history using backups (per another suggestion), you need to retain
>> one backup per significant event. That can add up.
> Thanks! That's a critical issue for my case where there is a large &
> growing core data-set and where it might be useful to have hundreds of
> branches, each representing a particular configuration of a subset,
> slice, or view of the core data-set.
Don't hurt yourself getting too clever. And don't forget that once
ingested, Subversion is designed to *never let go* of content.
Deleting any in the master simply won't ever clear the content from
the core repository and its history, *ever*.
Why do I bring this up? Because if it's MP3's and you discover a
copyright violation, you cannot expunge the content without a *very*
painful dump, iflter, and reload operation on a quite large
repository.
> Since, in my case, the binary files should/must never change, is there a
> way to configure a read-only attribute on specific files in the
> repository such that any subsequent attempt to check-in a change to any
> of those files will be rejected and an alert raised? The directory
> structures should remain changeable.
That's what user privileges in "svnserve.conf" that would provide
"write once" control are designed for. It would *not* prevent
operations on the local file system by an administrator, using
"file:///" based access. I assume that if an admin performs that kind
of access, they mean what they're doing and are aware they're avoiding
the filters.
I also think you're being really optimistic about "my repository will
only grow and never need to actually clear content". Accidental
submission of copyright violating content would be my big worry. But I
tend to pay more attention to that kind of concern than most.
Received on 2016-08-13 23:31:37 CEST