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.
