The reason to put the work ID/ticket ID in the commit message is so that if, for example, there is a problem, say in an stored proc file, you can use the ID from the commit message to look up the task and give context as to why this change was made. Or to see what other files where changed at the same time. Without that you could "fix" something whilst break the work done by the task that changed it.
Thanks all that you have said is interesting, thanks for taking the time to explain. On reflection I think that (for me) the SVN Commit Message is not the place I would drive that from. I have that (ticket) information in (a comment) the source code (which is probably only any good for "For Info"), but more usefully for me I have the means to see (for a given ticket) what source code was changed. For us it would be very rare that a single checkin matched a single work ticket. Cross reference between tickets causes us to try to mop up any related jobs at the same time, and I wouldn't bother to checkin more than once a day, often less frequently. We are a small shop though ... if I was trying to land on Mars I reckon I'd need something far more sophisticated ...
This is a bit of a tangent, hopefully that's OK :
My Time Sheet record requires me to enter the ID of associated Work Ticket. So I know who/when/how long that Ticket was worked on.
Every individual script file we have (Sproc / View / Trigger / Function etc.) has a "Script Run Log" Sproc call at the top to Log the Object name, Version, Who, When, etc. So if you run the script (success or fail) it gets logged. If you (or more likely a Big Rollout Patch Script) runs a bunch of script files, each one gets logged in turn (and as part of rollout we check that QA matches DEV, and then that PRODUCTION matches QA 🙂 )
So I can find all changes that (that developer) made during the time period of their timesheet entry/entries (for a given Work Ticket)
The Log only says that the Script was run, not that it was successful. If the code is for an ALTER and there is a syntax error then I will have a LOG record but no change to the object. (i.e. in that instance the Log Record date will be newer than the MODIFY date of the object.)
We also have a DDL change trigger which logs the DDL change ... so I can also use that to find any actual changes to the object - also whether the ALTER was successful, or not (and also the Before/After code content)
So I can report on:
For a given ticket JOIN to all the timesheet entries and JOIN to the Script Run LOG and the DDL Change Log to find all the "events" that occurred.
This is of course not dependent on me putting a good, accurate, Company Policy Compliant [Newbies may muck up here ...] and truthful 🙂 Commit Message
The DDL Log also has all the "actual source" of the various modifications that were made. SVN will (for me) only give me the next checkin - for us that only happens after the work has been successfully completed and that will most likely include "other work done today" (but I can see that "Checkin after each Ticket" would be a suitable alternative)
... This presents you with a web front end that shows the changed files from those commits in tree view. As you select each file it shows you a diff' on the right. The code reviewer can then highlight individual lines or multiple lines and add a comment, e.g. "select * is bad practice in a query returning data, change it to select column names". You can mark the comment as "needs resolution". After the developer has made the changes and, optional, replied to the comments on the review, the new commits can be added to the review and you can then mark the comment as resolved.
That's a million times better than my method 🙂 As is happens we already have a very slick DIFF plugin in our DEV web system (usually used to compare CMS Template Content changes ...). It has never occurred to me to hook that up to changes in Sprocs etc. and build THAT into a Code Peer Review system. I'm not sure I even need SVN to get the history, its in my database log backups and the DDL Log. I'll have a look to see if I can hijack that to do my Peer Review from there. I am pipe-dreaming, but perhaps I could also hook that up to our Help Centre too so that I could "improve" the Coding Standard Articles where code peer review finds something sloppy and, shamingly, the coding standards DOCs are equally sloppy!
FYI - we literally just got a test migration of our projects SVN repo to Git hosted in AzureDevOps done the other day. It took me a while to figure it out and get it right. It takes about 26 hours to migrate nearly 20K commits, because I want to keep the SVN commit history but it worked in the end. If you don't care about your commit history or tags then you can simply just take a snapshot of your latest codebase and be done inside an hour or 2.
I've been thinking for years that we should move to something more modern than SVN, particularly something "distributed" (if that is the right word) where I could check in my partially debugged code without actually committing it to the tree until I've actually finished that job. That would help me with jumping between my desktop PC and a laptop when out on the road (except I haven't been "out on the road" for a year so that requirement has been moot recently ...)
But I'm terrified of the change and what I might lose or hidden snags that will then be uncovered. Just the standard change-resistance of old age (and some accumulated wisdom, with age, too I dare say!). There is no way I would give up my change history 🙂 but a one-off migration that took a whole weekend to run would be acceptable. We are a small shop I doubt it would take that long. SVN reports 7,500 commits, 15K files, 500MB