Re: Can I prevent a file from being modified?

On 7/16/11 3:14 PM, David Myers wrote:
> Dear subversion,
>
> I have recently started a new post and I am in the process of investigating some
> possible new working practices. This particularly relates to document control.
>
> I have read in various places about the 'tagging' system (where by I can use a
> property to effectively 'name' a file) used by subversion and things such as
> svn:needs-lock that forces any user who tries to commit a change to a file to be
> asked to acquire the lock that the file holds.
>
> These almost fit my requirements, but not quite.
>
>
> What I require is a method where I can make the file truly 'read only' after a
> certain point.
> From what I have read in various places I thing I understand that...
> subversion reflects the unix style permissions on it's subdirectories, in the
> subversion directory tree.
> If I want to make a specific location 'read only' I need to do this from a new
> directory, and then files in this directory will acquire the permissions of the
> parent directory.
> subversion doesn't store the file permissions of a file directly it stores it
> within the svn:properties
>
> However if the above statement is correct this may not fill my requirements.
>
> Let me expand on my problem (situation).
>
> A group of users may be working on a file over time. At a certain point they all
> agree that the file is up to its required needs and they formally create a hard
> copy of this file, and store it as a controlled document (signed and counter
> signed blah blah blah).
> The finalised hard copy of the file must be an exact match of the copy stored
> electronically. All the users will be aware that this file shouldn't be change
> on the disk. But life being life when a user opens the file to print it they may
> inadvertently add a space in a paragraph, or an accidental carriage return, or worse
>
> how often have you been working on document1 when you get that phone call to
> ask about a specific part of the controlled document2, so you open the
> document to have a quick read and clarify the situation. Then you get
> distracted by something else and you return and start editing the document2,
> thinking you are editing document1.
> We all know it shouldn't happen but it does occasionally.
>
> What I want to be sure of is that even if this is done by accident there is no
> way that the file on disk in the subversion repository can be inadvertently
> changed. The svn:need-lock property combined with another personal property
> (something along the lines of CtrlDoc:DO_NOT_CHANGE TRUE ), unless there is an
> svn:read-only property that I am yet to come across!
>
> I feel that the combination of these properties and proper use of the Head,
> commit and branch strategies should enable myself and my users to ensure that
> these types of problems don't occur.
>
> Please help me clarify this so as I can propose the use of a subversion to my
> colleagues, and give eloquent and correct answers to any of their queries.

First, subversion provides mechanisms to check for changes against a specified
revision and to retrieve specified revisions into your working copy. Perhaps
you can formalize the way you specify the revision(s) you want to be using or
add checks for changes in files subsequent revisions in your workflow and relax
the requirement to disallow changes. Version control systems are more about
tracking changes than preventing them. If you ask for a specific revision it
will always be the same regardless of changes in subsequent changes. Tags are
sort-of a special case of this where a directory at a certain revision is copied
to a name where you reference it more easily - but you'd get exactly the same
results if you retrieved the source directory of the tag copy and specified the
revision number. Because of the way tags are used, they are normally not
modified after the copy that creates them, either just by convention or by a
pre-commit hook that disallows changes to existing files. If you want to tweak
things at that level, you could modify your pre-commit hook script to prevent
changes to any files you want.

-- 
   Les Mikesell
    lesmikesell_at_gmail.com