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?
+1
A:
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.
Dave Bacher
2010-07-22 00:10:10
We have a couple set ups. One is TFS where everything is 'submitted' and then checked in only after building and unit tests are executed.Then we have a rolling build, which is what you suggest. I much rather test before checking in to ensure the repository is always builds.
Steven
2010-07-22 00:18:03
A:
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.
krock
2010-07-22 00:25:08
That is a debate. Having done both I can say that it is not 'drawn out'. Most projects only take a minute or two to build and a minute or two to test. There is also the argument that you don't have to rely on developers to make sure tests are passing before they checkin ... which is usually the case anyway.
Steven
2010-07-22 00:29:46
@Steven, I would consider a pre check-in build/test as more of a smoke test. Maybe a pre commit hook will suit your needs.
krock
2010-07-22 00:42:42
+1
A:
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.
- build server runs build for someone's commit
- all tests pass, so it merges/commits the change to another branch/repo
- 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.
Joshua McKinnon
2010-07-23 00:59:43