Re^7: [OT] Best Use of Subversion Branches in Perl Development

What annotation tools are you talking about? If I had ever seen one, I'd be more interested in using techniques that work with it.

For human use, a simple "merging tag 2.001" commit message has been fine. Maybe you're thinking of a more complex situation than Jim or I have. In my case, we always merge the tag with the latest version, so looking up the last merge isn't necessary if the tags are sequential. The additional information of which revision number the merge was hasn't ever been needed.

Comment on Re^7: [OT] Best Use of Subversion Branches in Perl Development

Replies are listed 'Best First'.
Re^8: [OT] Best Use of Subversion Branches in Perl Development by mugwumpjism (Hermit) on Mar 19, 2007 at 00:28 UTC
For instance, `svn blame` is one tool that comes with Subversion to do this - but of course since Subversion is so generally deficient it can't trace through merges. If you've done the sensible thing and converted the repository to git using `git-svn`, and successfully converted the merges, then `git blame`, the emacs `git-blame.el`, `gitk` visualisation of the history of the file, etc, can all be used and will correctly identify the change that introduced a line of code and not the one it was merged in with. No doubt the same thing applies to conversions to other suitable capable VCS such as Mercurial, bzr, etc. SVK and svnmerge have conventions for how they represent this information which does not suffer from the above problem. You could have easily picked from one of those, it would have been just as easy. $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n"; [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^8: [OT] Best Use of Subversion Branches in Perl Development
by mugwumpjism (Hermit) on Mar 19, 2007 at 00:28 UTC

For instance, svn blame is one tool that comes with Subversion to do this - but of course since Subversion is so generally deficient it can't trace through merges.

If you've done the sensible thing and converted the repository to git using git-svn, and successfully converted the merges, then git blame, the emacs git-blame.el, gitk visualisation of the history of the file, etc, can all be used and will correctly identify the change that introduced a line of code and not the one it was merged in with. No doubt the same thing applies to conversions to other suitable capable VCS such as Mercurial, bzr, etc.

SVK and svnmerge have conventions for how they represent this information which does not suffer from the above problem. You could have easily picked from one of those, it would have been just as easy.

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
[download]

[reply]
[d/l]