On Apr 22, 2013, at 15:13, Charles Gallo wrote: > Ok, IMHO, they are good enough, but not for my current client. They basically > want to append the Equivalent of blame or annotate to the actual source > code lines! > > So say in c# you'd see > > A++ //CAG 2013-04-13 > > Yep, they also don't want you deleting code, you comment it out... > > Their logic? The auditors can see it. > > Yeah, I've explained blame, but they are the client, and want to help them do > what they want, even if it is the wrong thing
Regardless what the client wants, Subversion doesn't do that. There are a number of courses of action. 1. Don't do that (or: don't want that). You already know this. 2. Is the information produced by "svn blame" sufficient, just in the wrong format? If so, write a wrapper script around "svn blame" to reformat it. For example, in your hypothetical file where CAG added (or modified) the line "A++" on 2013-04-13, the output from "svn blame" might be: 105 CAG A++ (assuming 105 is the revision in which that change was made). You could easily use `sed` to transform this to: A++ // CAG r105 If "r105" is not sufficient but you want a date (which is of course less precise than a revision…) you could somewhat less easily look up each revision's date and print that instead. If you want to prevent deletions of lines, install a pre-commit hook that enforces that rule. 3. If you want the actual source code in the repository to contain these comments, then you're talking about several scripts: one that the developers must invoke in place of "svn commit" to commit their work, which transforms their files in the ways you desire before committing them, and another that runs as a pre-commit hook and verifies that the incoming commit conforms to these requirements (and rejects the commit if not). 4. Find a different version control tool that better fits your client's needs. (I'm not aware of any that do this, but I also don't know a lot about version control tools other than Subversion.)
