Commit to subversion on behalf of someone

Is there a way to checkin a change on behalf of someone? For example, I want to process changes through some kind of build server and then have the build server check it 开发者_运维知识库in for the user.

Is that doable?

I am not aware of a direct way to directly commit on behalf of someone...but you can probably do it with a revprop edit if you write a pre-revprop-change hook. See: pre-revprop-change hook doc

Revision property edits are disabled unless a pre-revprop-change hook exists. The idea being that the script should determine whether or not to allow the property edit, based on the property being edited, the user, etc.

You could write a pre-revprop-change hook that only allows changing of the username property by some admin user that the build server uses for credentials, and have that alter the username after the commit.

1. build server runs build for someone's commit
2. all tests pass, so it merges/commits the change to another branch/repo
3. edits the revprop username for that commit

Revision properties are not versioned in Subversion, so it would be like it was always from that user. It seems reasonable enough, but someone correct me if this is a bad idea. Just make sure your hook does exactly what you want - create a test repository to experiment and test it thoroughly.

You can specify the user and password on the command line:

svn commit --username user --password pass [files]

Are you thinking of using a specific build server? Many Continuous Integration servers operate with the user performing commits to the repository and the CI server verifying that builds still work (and performing tests and reporting on lots of other metrics). I'm partial to Hudson myself.

You can add a pre-commit hook on the svn server which is a script that will be triggered when a user checks something in. You can use these hooks to prevent commits if they don't pass the requirements of the hook script.

I wouldn't recommend longer drawn out processes, potentially such as building the source prior to commit. The longer it takes to check in your changes, the greater chance that someone else will have merge conflicts later on.

Developers should be compiling/testing their changes before they checkin anyway and this will provide some level of reliability of the changes (works for me). A continuous build should run after checkin to check that all changes work and run unit tests. If at this stage the build fails, then the user responsible has the choice of fixing the changes or rolling them back.