On 08/13/2016 09:33 PM, Branko Čibej wrote:
> There is (currently) no easy way to specify "write once" access for
> files in the repository; whoever can create a file can modify or delete
> it, too. You could achieve something like that by creating a custom
> pre-commit hook that would examine the pending commit transaction and
> reject the commit if it finds modifications or deletions of existing files
Thanks. I have svnserve configured and ready for a few tests that should
enable basic characterization of the system in this use-case. I suppose
I could concurrently develop familiarity with the command and operation
of this setup while I explore customization of its functioning.
Tonight is for contemplation but I imagine testing and hook scripting
will begin within the next few days.
Does anyone have any comments on using Tcl as a hook scripting language?
> But note that a rename is represented as an add+delete, so the hook
> would have to be rather smarter than it would seem at first glance to
> detect and allow renames without content modification.
The literal file names are composed of a date and a sequence number, and
like the contents of the files, the names should never change. The core
data-set directory structure (trunk, maybe) will most likely be
calendar-like (years->months->days->sequence->file). The analysis tools
and meta-data will probably be kept in a separate fossil[1] repository.
[1]: http://www.fossil-scm.org/
The near-term goal is to maintain an indelible record of the physical
measurements of reality. Any analysis [of which, there will be plenty],
annotations, and other meta-data generation must not alter the
fundamental instrumentation data.
Given that, by "rename" do you mean a change of the literal file name
like what I tried to describe above, or are you referring to something
more like the file references, links, or pointers within the repository
[internal implementation], similar to David's use of the term "rename"
(included below)?
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.
Received on 2016-08-14 22:22:31 CEST