Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of ben@reser.org designates
 50.197.89.41 as permitted sender)
Message-ID: <53C98724.9090708@reser.org>
Date: Fri, 18 Jul 2014 13:44:20 -0700
From: Ben Reser <ben@reser.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Caitlin Matos <caitlin.matos@zoho.com>, users@subversion.apache.org
Subject: Re: Probable bug: writes commit messages to read-only trees
References: <147453512de.-6425457871167331501.125426258589227782@zoho.com>
In-Reply-To: <147453512de.-6425457871167331501.125426258589227782@zoho.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 7/17/14 10:16 AM, Caitlin Matos wrote:
> I attempted to add and commit a file to a new repo that I *should* have
> read-write access to. I still can't figure out whether I really have RW or RO
> access, but I think this is irrelevant.
> 
> When I committed the file, I received the following message:
>       Adding         watchfiles/xdg-utils_1.1.0~rc1+git20111210.watch
>       Transmitting file data .
>       Committed revision 289.
> 
>       Warning: post-commit FS processing had error 'attempt to write a readonly
> database'.

This means the rep-cache.db file is not writable by the server.  You should
report this to the server admin.  I would guess that the $REPO/db/rep-cache.db
file has the wrong permissions on it.

The rep-cache.db is an optional add-on to the repository.  It's used for
de-duplication when commiting identical content that's independently created
(i.e. not via svn cp).  If the file is deleted or missing the worst that can
happen is that the repository ends up taking up more space than it would
otherwise.  Specifically it's a simple key/value set with the key being the
SHA1 hash of the data and the value being where the representation of that can
be found.

You don't mention what version of Subversion is on the server (and I don't
really expect you to know since it sounds like you're not running the server).
 However, newer servers should report something like this now:
Warning: post commit FS processing had error:
Couldn't open rep-cache database

I couldn't find exactly the error message you provided and this baffled me for
a bit until I duplicated the situation I expected and saw the message contained
("post commit" as opposed to "post-commit").  When reporting issues it is very
helpful to make sure you transcribe the output exactly.

> When I browsed the repo online, I can see that the history has indeed changed,
> and it references a file that does not exist on the server.

Are you sure about that?  Because the output you posted above is not consistent
with that.  Your commit should be stored in a complete and accurate way.

> This is very odd behaviour. SVN is writing to the log, THEN attempting to
> upload the file, and if the upload fails, the log persists.
> 
> Suggested behaviour: one of:
>       1) determine RO/RW access before writing commit to log; refuse to commit
> if RO
>       2) keep as is, but when RO error encountered, undo the commit.

Subversion already works this way.  We build up a transaction (which requires
write access) and then commit the transaction.  The Adding line in your output
is from when the structure of the tree is being sent.  Transmitting file data,
is from when the actual contents of the file is sent.  Committed revision 289,
is when the transaction is converted to a new revision.  If anything fails
during the creation of the transaction or the conversion to a revision then no
change takes place.

The rep-cache write has to happen after the commit because representations of
content aren't permanently stored in the repository until the commit completes.
 Since the rep-cache isn't required for normal operation this doesn't present a
problem, failed modifications of the rep-cache.db simply display the warning
you saw.