Re: Making file immutable in working copy

Hello David,

thanks for the response. I am afraid, however, these solutions
all work server-side. I needed a client-side method, since in the
scenario that I assumed, the server has been compromised.

* Message by -David Weintraub- from Thu 2008-09-25:
> There are a whole slew of pre-commit hooks that can do just this. In
> fact, this is probably the most popular request for a hook.
>
> The most common one is written in Python, and there's an older Perl
> version that isn't quite as flexible as the Python version, but will
> do exactly what you want.
>
> Both hooks will allow you to lock a specific file, specific directory,
> or specify a group of files via a regular expression. You can specify
> that no one can touch a file/directory or that only certain people
> can.
>
> That way, you can have two people work on one project, but not allow
> other people in your group to touch a project, or you can freeze a
> project, so people can check it out, but not modify it.
>
> Take a look at <http://subversion.tigris.org/tools_contrib.html#hook_scripts>
>
> The two you're looking at are:
>
> commit-access-control.pl (and commit-access-control.cfg.examples)
> enforcer (and enforcer.conf) -- this is in Python
> --
> David Weintraub
> qazwart_at_gmail.com
>
>
>
> On Thu, Sep 25, 2008 at 3:13 PM, Lasse Kliemann
> <lasse-subversion-users-2004_at_plastictree.net> wrote:
> > How do I make a versioned file in a working copy immutable, i.e.,
> > prevent it from being changed (especially from being deleted) by
> > subsequent 'svn up' operations?
> >
> > Removing the write permissions in the file system is not
> > sufficient. One could use 'chattr +i ...', but that involves
> > superuser privileges (or special capability settings). There must
> > be a simpler way.
> >
> > Rationale: I know that one can always get an old version of the
> > file from the repository. However, I am concerned with the case
> > when the server holding the repository is compromised. Yes, then
> > I play in a backup. However, my users want to be as independent
> > as possible from any centralized solution; they want to rely on
> > certain files never changing in their working copies, at least
> > not without their explicit consent.