Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of brane@wandisco.com designates
 209.85.212.181 as permitted sender)
Message-ID: <54076DFC.206@wandisco.com>
Date: Wed, 03 Sep 2014 21:37:32 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: users@subversion.apache.org
Subject: Re: Commit bot without password
References: 
 <CANt7B+dKz5apwCJs8rT1vgBZuJ7-UTehXni5pfHxKA5AZd6ojA@mail.gmail.com>
In-Reply-To: 
 <CANt7B+dKz5apwCJs8rT1vgBZuJ7-UTehXni5pfHxKA5AZd6ojA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2014 21:21, Kim Gräsman wrote:
> Hello,
>
> I'm new to the list, so forgive me if this has been discussed before.
> I didn't find anything in the archives.
>
> At my workplace, we run a simple home-cooked "gated commit" system on
> top of Subversion 1.8. Users run their working copy changes through a
> client program, it assembles all changes and sends them with a work
> order (what to build, test and run other analysis steps for) to a
> server, which runs all steps and commits on the user's behalf if they
> pass.
>
> This works really well for us, but we haven't been able to avoid
> sending the user's SVN credentials together with the work order, and
> this is clearly not desirable.
>
> Is there some way to convince Subversion to commit on a user's behalf?
> We'd like to designate one SVN account as the commit bot account and
> let it impersonate users at will.

The standard command-line client won't let you do that. It's possible to
write a script or program, using our bindings or API; but it's rather a
lot of work.

You could try the following trick: on the build machine, with the bot's
credentials, do this:

    $ svn commit -m ... --with-revprop on-behalf-of=username

then on the server, add a pre-commit hook script that looks at the
revision properties of the transaction (svnlook propget --revprop)
that's about to be committed; and if svn:author is the bot, and the
on-behalf-of property exists, the script would replace the svn:author
value and delete the on-behalf-of property (svnadmin setrevprop).

This is just a blue-sky idea, I've never actually done that; but I don't
see a reason, offhand, why it wouldn't work.

-- Brane