Is there a means to produce a changelog in SVN

Question

When commiting to SVN I can add a top level commit message to detail what is being committed, but I would ideally like a means to comment on the individual files and what has changed within them. I have seen something similar in previous employment, but this was using CVS (and I can't recall whether this was achieved with a home brew script to produce the skeleton file)

I have had a look at changelists but again I don't think (although i am willing to be proved wrong) that this gives the kind of granularity as outlined below.

Ideally I am looking for something along the lines of:

Foo.vb

• Added new function bar

Bar.vb

• Removed function foo
• Added functionality in xyz to do abc +/- Modified function to log error

Answer 1

I would just do this in the individual commit message. TortoiseSVN has filename autocompletion so that greatly aids in this.

Another thing you could do is svn st before you commit and copy/paste the filenames into your commit message.

Oh, and be sure to strongly question the value of this. I know some OSS projects (linux?) require this sort of fidelity, but for many projects this is just noise. Diff can tell you much more than this, and more accurately.

One other thing you may want to consider is using Git. Git allows you to commit locally, in smaller steps. You then push to the master server all of your commits individually or squashed into a single commit w/ all the commit messages in a single message. That was a way simplified explanation, but it probably is worth checking out.

Answer 2

You could just commit whenever you're done with one particular task. That should lead to better comments anyway. A comment reading "Implemented E-Mail verification" on the three files necessary tells me a lot more than "added function verify_email". I can see the latter myself in the diff.

Answer 3

That kind of result could be obtain if there is some rules regarding the way comments are written inside each of the committed files. These comments can after that be extracted by a svn trigger.

Answer 4

One of the essential differences between SVN and CVS is that changes are committed atomically. In CVS each file has its own version, but in SVN the version is for the whole project and includes all the files checked in together.

Here are four ideas for a solution:

1. Check in each of your programs separately, with its own log message. This may mean that if, say, you check in five files, you will "use up" five versions, of which four may result in a broken build.
2. Do your development on a separate path (i.e. your own private branch), do as above, then at strategic moments merge your branch to the trunk.
3. Check in everything together, and keep the individual records as comments in the program header. This may mean (a little) extra work, but you'd have to compose the individual login messages anyway.
4. Do a single checkin for all the files, but with a nice full log message detailing each piece for each file.

Answer 5

I've written a project for doing this kind of thing called MOAP

One of its functions is to generate a ChangeLog entry from your local diff (currently supporting bazaar, cvs, svn, git and darcs). You do this by running 'moap changelog prepare' or 'moap cl prep' That entry can include functions changed as well if you enable the option.

You then go and change that entry, describing your changes. You can remove files you don't want commited as part of your next commit.

Then, you can run 'moap changelog commit' to commit the changes described in the ChangeLog entry. It will only commit the files listed there, and leave all your other changes local.

Hope that helps!