How to make Subversion (or any program) perform periodic commits?

Question

I want to configure my computer so that say every half an hour it automatically commits the program I am working on. I am using a svn repository so even if it was just a script that ran 'svn ci' every 30 min that would be okay. The problem is that I don't know how to do that.

Could somebody please tell me, or direct me to something, that would let me get this periodic commit stuff working?

Thanks in advance.

EDIT: Sorry it appears that I have confused people as to why I would want to do this. The sole reason that I want to do this is because a lecturer of mine wants us to know how our code develops over time and I thought that it would be a great idea to use svn for this purpose. It does not matter if the latest commit works or not. It just has to show the changes I have made to the code over time.

Answer 1

If you are running on a flavor of UNIX consider creating a cron job to run commands at a regular interval.

Answer 2

You could try a cron job that runs a shell script. What OS are you on?

But I'm curious as to why you'd want to do this. Your commits should consist of pieces of functionality or bug fixes, and not based on a time interval. You're likely to commit in the middle of a change (on a group of files) which will render your revisions useless.

Answer 3

I don't think setting commits on a timed schedule is a particularly good idea. Especially if you start getting into testing and continuous integration. Committing at set intervals will break the build because there is no guarantee that you will have completed the changeset in the time frame.

A better way, if you want to auto-commit is to make the commit part of the build process itself. Just make the last step of the build process a commit to the repository. That way, if the build fails, you won't commit garbage.

Totally possible with all flavors of make and I know Visual Studio has pre and post build events that can be set to do something like this. So I'm pretty sure that most modern IDEs can handle this.

As a special consideration for this problem in particular:
Move the commit hook to the beginning of the process so you can track when you mess up royally as well and how you come to fix the errors.

Answer 4

Contrary to apparent popular opinion, I think this is a great use of svn, in the context of the assignment.

Tools like kdesvn (or even better, tortoisesvn, but that's only on windows) might give you great insight into what's happening with their log views, diffs and blame visuals.

If you're using ubuntu, run this bash script from a console that's separate to the one you're working on.

#!/bin/bash
while [ 1 ]
do
        # Do the commit
        svn ci --message "Automated commit" ~/yourworkingcopy

        # Wait until next commit time
        sleep 1800
done

Answer 5

I would use Subversion, but I would instead just get into the habit of working on single changes, and comitting those to a repository.

This way the lecturer, if he wants to, can look at not only what changed, but why it changed. This would be much more useful I would imagine.

Answer 6

I would not dirty your control version system with such series of auto commits. But I agree with the idea of using a control version system to provide that information.

Then, my suggestion is: use a repository for your software and another one for store the auto commits. When the work is done, merge all auto commits in the main repository in only one logical commit.

With git, I would do this:

1. Repo 'foo': the main repository
   1. refs/heads/...: the location of your development branches
   2. refs/sessions/...: the location of your work with dirty commits.
2. Your working copy:
   1. "git init"
   2. "git remote add foo git://foo/...; git fetch foo"
3. create the branch: "git checkout -b bar foo/master"
4. tag the begining of the branch: "git tag barbegin"
5. activate the script: "while true; do git add -A .; git commit -m 'autocommit'; done"
6. I would not use a cron job, so you can activate/deactivate the autocommits easily.
7. do your job
8. after your job done, deactivate the script
9. commit pending changes
10. now, you have a lot of auto commits in branch bar, and you have tagged the initial commit of the branch with barbegin
11. publish your auto commits:
    1. "git tag barend"
    2. "git push foo barbegin:refs/sessions/your user id/the session id/begin"
    3. "git push foo barend:refs/sessions/your user id/the session id/end"
12. now, you have published your work and your lecturer may access it
13. for update your foo repository:
    1. "git rebase -i --onto barbegin barbegin" and proceed as described here
    2. I would squash all commits: "in the end, there can be only one".
    3. "git push foo bar:master" # only one commit will be pushed
14. cleaning:
    1. "git tag -d barbegin"
    2. "git tag -d barend"
    3. "git branch -d bar"

After all this, I think no useful information may be gathered with such kind of data. So, I would try to avoid this workflow. But if really needed, I would do that way.