Re: Blame/annotate not good enough...
On 23.04.2013 16:29, Thorsten Schöning wrote: Guten Tag Charles Gallo, am Dienstag, 23. April 2013 um 14:22 schrieben Sie: Blame/annotate does exactly what I want, but the client (mumble mumble) wants the info in the actual source code file as comments! I explained that all the info is in blame/SVN, but they actually said the auditors won't see the repository, just the source, and they want to be able to see what changed and by whom. That's why I'm not allowed to delete code, only comment out. Sigh Maybe you should try a different approach: Why do the auditors don't have or want access to the repo? May read-only copy of the repo to access offline a solution? You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
RE: Blame/annotate not good enough...
On Apr 23, 2013, at 15:56, Daniel Shahaf wrote: Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 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). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. Appends the blame-comments to what? Certainly not to the file in the repository because by post-commit time the commit is already finalized. And you wouldn't want to modify the transaction in the pre-commit hook because that would screw up working copies. Are you suggesting the server should make a second commit after every commit to add the blame-comments? That would totally mess up normal use of svn blame, among the other usual problems. I agree. It seems to me that a CI build process should be generating BLAME audit documents for the auditors that could be checked into another repository. The devs should OWN the source, not the auditors! BOb
Re: Blame/annotate not good enough...
On Wed, Apr 24, 2013 at 7:35 AM, Branko Čibej br...@wandisco.com wrote: You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. Can't they at least deal with a web view generated by viewvc or websvn? Or a printout of those views? -- Les Mikesell lesmikes...@gmail.com
Re: Blame/annotate not good enough...
On Wed, Apr 24, 2013 at 8:35 AM, Branko Čibej br...@wandisco.com wrote: On 23.04.2013 16:29, Thorsten Schöning wrote: Guten Tag Charles Gallo, am Dienstag, 23. April 2013 um 14:22 schrieben Sie: Blame/annotate does exactly what I want, but the client (mumble mumble) wants the info in the actual source code file as comments! I explained that all the info is in blame/SVN, but they actually said the auditors won't see the repository, just the source, and they want to be able to see what changed and by whom. That's why I'm not allowed to delete code, only comment out. Sigh Maybe you should try a different approach: Why do the auditors don't have or want access to the repo? May read-only copy of the repo to access offline a solution? You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. -- Brane I have. The key is to get to the auditor, themselves, not the people who interpret what the auditor told the person who took the specs for the person who managed the person who wrote the gant chart for the person the auditor reported person to who interpreted it for your boss. Etc., etc., etc. It's very helpful to speak directly to the person who has to do the audit, and find out what *they* can handle directly. They're often quite reasonable and willing to cooperate in setting up a more efficient transfer of knowledge. It's often the layers in between that make things. strange.
RE: Blame/annotate not good enough...
-Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: dinsdag 23 april 2013 08:46 To: Charles Gallo Cc: users@subversion.apache.org Subject: Re: Blame/annotate not good enough... 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: To get you the 'svn blame' / 'svn annotate' output your Subversion client reads all the full versions of the file that existed since the file was created. The current format is just one of the possible output formats that we can calculate from that information. We are looking at rewriting the blame calculation code in the near future for improved performance and if you have suggestions on how we can provide a format that provides you the information you need we might be able to implement it. And if it is not a generic solution we might be able to help you build a custom solution on top of the API. The current output format is probably borrowed from the original CVS output and is pretty limited by what we can show in simple characters or simple XML. If you use a GUI where you can use colors/strike-throughs, etc. far more things are possible. And I'm pretty sure there are more Subversion users that want improved review capabilities beyond what 'svn blame' currently provides. Bert
Re: Blame/annotate not good enough...
On Apr 23, 2013, at 8:47 AM, C. Michael Pilato cmpil...@collab.net wrote: Get different (and clueful) auditors? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development I think it is more the client. I've pointed out their options, so I'm trying to automate a pain point. Other than this, and a few other strange points, they are a good client. Ok pay, they pay on time, treat me well, and easy commute.
Re: Blame/annotate not good enough...
Guten Tag Charles Gallo, am Dienstag, 23. April 2013 um 14:22 schrieben Sie: Blame/annotate does exactly what I want, but the client (mumble mumble) wants the info in the actual source code file as comments! I explained that all the info is in blame/SVN, but they actually said the auditors won't see the repository, just the source, and they want to be able to see what changed and by whom. That's why I'm not allowed to delete code, only comment out. Sigh Maybe you should try a different approach: Why do the auditors don't have or want access to the repo? May read-only copy of the repo to access offline a solution? If the auditors just need the info about who changed what as inline comments in the source, because they aren't allowed to access the repo or else devil himself will kill the world ;-), how about a process generating what they need as an on demand process? They need access to the code somehow in any way, maybe you could create the view your client wants as a part of some export or preparation process using the source code repo you seem to have access to? You could even build some nice little GUI especially for the auditors if your client pays well and in time. ;-) Focusing on specially formatted commits or stuff like that may not be the only solution. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Blame/annotate not good enough...
Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 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). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. And figure out a way to address the race condition (another dev commits before post-commit runs).
Re: Blame/annotate not good enough...
On Apr 23, 2013, at 15:56, Daniel Shahaf wrote: Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 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). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. Appends the blame-comments to what? Certainly not to the file in the repository because by post-commit time the commit is already finalized. And you wouldn't want to modify the transaction in the pre-commit hook because that would screw up working copies. Are you suggesting the server should make a second commit after every commit to add the blame-comments? That would totally mess up normal use of svn blame, among the other usual problems.
Re: Blame/annotate not good enough...
Ryan Schmidt wrote on Tue, Apr 23, 2013 at 16:52:10 -0500: On Apr 23, 2013, at 15:56, Daniel Shahaf wrote: Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 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). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. Appends the blame-comments to what? Certainly not to the file in the repository because by post-commit time the commit is already finalized. And you wouldn't want to modify the transaction in the pre-commit hook because that would screw up working copies. Are you suggesting the server should make a second commit after every commit to add the blame-comments? That would totally mess up normal use of svn blame, among the other usual problems. Actually, that's exactly what I was suggesting. And I'm well-aware of the fact that it would break normal 'blame', but considering the feature that post-commit hook would be implementing I don't consider it that much of a problem (not to mention that simply moving the comment to be _above_ rather than _at the end_ of the line it describes addresses that concern). *shrug* Another option is to have a shadow repository --- basically, like an svnsync mirror, except that each slave file is 'svn blame -v' of the source file rather than 'cat' of the source file. Maybe there are other solutions, but there's a limit to how much I'm willing to think about this particular requirement in my spare time.
Re: Blame/annotate not good enough...
On Apr 23, 2013, at 7:55 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Maybe there are other solutions, but there's a limit to how much I'm willing to think about this particular requirement in my spare time. Ok guys, don't worry about it. I was sort of hoping someone had a semi easy way. Not worth the pain to automate at this point. Thanks you for the help!
Re: Blame/annotate not good enough...
Charles Gallo wrote on Mon, Apr 22, 2013 at 16:13:25 -0400: Any ideas on how to do this? Probably some sort of pre commit hook, but... but pre-commit hooks can't modify the in-flight txn without breaking the committing working copy.
Re: Blame/annotate not good enough...
On 4/22/2013 Daniel Shahaf wrote: Charles Gallo wrote on Mon, Apr 22, 2013 at 16:13:25 -0400: Any ideas on how to do this? Probably some sort of pre commit hook, but... but pre-commit hooks can't modify the in-flight txn without breaking the committing working copy. Ouch... So, ideas? (forgot to CC the list the 1st time) -- -- Charlie www.baysidephoto.com www.thegallos.com
