You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Charles Gallo <ch...@thegallos.com> on 2013/04/22 22:13:25 UTC
Blame/annotate not good enough...
Hey Gang,
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
Any ideas on how to do this? Probably some sort of pre commit hook, but...
Re: Blame/annotate not good enough...
Posted by Charles Gallo <ch...@thegallos.com>.
On Apr 23, 2013, at 8:47 AM, "C. Michael Pilato" <cm...@collab.net> wrote:
>
> Get different (and clueful) auditors?
>
> --
> C. Michael Pilato <cm...@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...
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/22/2013 08:55 PM, Charlie Gallo wrote:
>
> 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?
Get different (and clueful) auditors?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Blame/annotate not good enough...
Posted by Charlie Gallo <Ch...@TheGallos.com>.
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
Re: Blame/annotate not good enough...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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...
Posted by Charles Gallo <ch...@thegallos.com>.
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...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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...
Posted by Bob Archer <Bo...@amsi.com>.
> 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...
Posted by Ryan Schmidt <su...@ryandesign.com>.
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...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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...
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
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...
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
Re: Blame/annotate not good enough...
Posted by Branko Čibej <br...@wandisco.com>.
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...
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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...
Posted by Charles Gallo <ch...@thegallos.com>.
On Apr 23, 2013, at 6:31 AM, "Bert Huijben" <be...@qqmail.nl> wrote:
>
> 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
>
Bert,
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
RE: Blame/annotate not good enough...
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2012c@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...
Posted by Branko Čibej <br...@wandisco.com>.
On 23.04.2013 08:45, Ryan Schmidt wrote:
> If you want to prevent deletions of lines, install a pre-commit hook that enforces that rule.
That would be quite hard to enforce, since it's not obvious just from
looking at (e.g., diffing) two files which lines were actually deleted
by the user. Diff doesn't show that; it tries to show the minimum set of
differences between two files.
In other words, you'd have to invent a much smarter algorithm with a set
of heuristics tailored for your specific editing rules.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Blame/annotate not good enough...
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.)