Re: Feature request: svn log constrained by line range
On Fri, Apr 7, 2017 at 4:50 AM, Joel Polowin wrote: > Hi, all. This is my first post to this list, but I've been a member > on many others. > > I'd like to make a feature/enhancement suggestion for svn. Would you > please let me know how I might do that? Or of course I'd be happy if > someone can tell me how to do what I want with the existing features, > though a couple of people in my group who are more experienced than > I am with svn haven't been able to figure out how it might be done. > > In case posting to this list is sufficient... I'd like to be able > to specify a line range for a file so that _svn log filename_ would > show the change log for only those lines, allowing for the movements > of the first and last lines through the file's history. So if my file > 'blargh' has a function which currently begins at line 1500 and ends at > line 1800, the command "svn log blargh --lines 1500:1800" would give > me the commit messages for that function even if that block of lines > was originally added to occupy, say, lines 2700 to 3500. And wouldn't > report the messages for commits that didn't touch that block of lines. > > This would help to resolve a conflict in my work group regarding good > practises for code documentation. :-( Interesting question. In theory svn could do this ... it's sort of a combination of 'blame' and 'log'. The information is there. But at present there is no functionality exposed for this in the client. * 'svn blame' works by invoking 'get_file_revs2' on the repository, retrieving all revisions, and processing the diffs between them, sequentially. It keeps track of which rev / author last touched each line (in the end it outputs the final result: each line with its corresponding "last rev / author"). See the source of libsvn_client/blame.c [1] for a starting point. * Your 'svn log Filename --lines 1500:1800' could similarly walk the history of the file with get_file_revs2. It would need to keep a list, per line, of all revisions that touched the line. And at the end output the log of all revisions that are applicable to the range of lines given. You might be able to write this, purely client-side, in C, or using one of the language bindings (python bindings or JavaHL), invoking the get_file_rev2 API. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_client/blame.c, see lines 809 and following, where it calls svn_ra_get_file_revs2, passing file_rev_handler as callback function. -- Johan
Repo for latest 1.9 svn binaries for 32-bit RHEL 6?
Does anyone on this list have a pointer to a repo that hosts the latest 32-bit (i686) Subversion binaries for RHEL 6? I’ve been using the WANdisco SVN Repo 1.9 (http://opensource.wandisco.com/centos/6/svn-1.9/RPMS), but it only has version 1.9.5-1 for 64-bit (x86_64). The latest 32-bit binaries in that repo are for version 1.9.4-1, which are almost a year old. Thanks, Alfred
Re: Feature request: svn log constrained by line range
On Friday, April 7, 2017 8:16 AM, Johan Corveleyn wrote: > On Fri, Apr 7, 2017 at 4:50 AM, Joel Polowin wrote: >> In case posting to this list is sufficient... I'd like to be able >> to specify a line range for a file so that _svn log filename_ would >> show the change log for only those lines, allowing for the movements >> of the first and last lines through the file's history. So if my file >> 'blargh' has a function which currently begins at line 1500 and ends at >> line 1800, the command "svn log blargh --lines 1500:1800" would give >> me the commit messages for that function even if that block of lines >> was originally added to occupy, say, lines 2700 to 3500. And wouldn't >> report the messages for commits that didn't touch that block of lines. > > Interesting question. In theory svn could do this ... it's sort of a > combination of 'blame' and 'log'. The information is there. But at > present there is no functionality exposed for this in the client. > > * 'svn blame' works by invoking 'get_file_revs2' on the repository, > retrieving all revisions, and processing the diffs between them, > sequentially. It keeps track of which rev / author last touched each > line (in the end it outputs the final result: each line with its > corresponding "last rev / author"). See the source of > libsvn_client/blame.c [1] for a starting point. > > * Your 'svn log Filename --lines 1500:1800' could similarly walk the > history of the file with get_file_revs2. It would need to keep a list, > per line, of all revisions that touched the line. And at the end > output the log of all revisions that are applicable to the range of > lines given. > > You might be able to write this, purely client-side, in C, or using > one of the language bindings (python bindings or JavaHL), invoking the > get_file_rev2 API. Hm. Would that cover lines that were deleted, rather than added or merely altered? That's one of my objections to a colleague's "just use 'svn blame'!" I was, of course, hoping to get away without undertaking a big programming task in a language I'm comfortable with (C), much less ones I'm essentially unfamiliar with (python, any flavour of Java). Ah, well. Joel
Re: Repo for latest 1.9 svn binaries for 32-bit RHEL 6?
On Fri, Apr 7, 2017 at 9:57 AM, Alfred von Campe wrote: > Does anyone on this list have a pointer to a repo that hosts the latest > 32-bit (i686) Subversion binaries for RHEL 6? I’ve been using the WANdisco > SVN Repo 1.9 (http://opensource.wandisco.com/centos/6/svn-1.9/RPMS), but it > only has version 1.9.5-1 for 64-bit (x86_64). The latest 32-bit binaries in > that repo are for version 1.9.4-1, which are almost a year old. > > Thanks, > Alfred I tried, some time back, to publish SRPM building tools for subersion-1.9.x and 1.8.x over at https://github.com/nkadel/. I eventually had to throw in the towel as the component dependencies for compiling the latest Subversion exceeded my time to backport and provide separate, system compatible builds of various libraries. But you're welcome to poke them and take a shot at getting it to RHEL 6. I also admit that with RHEL 5 and CentOS 5 obsolete, CentOS 6 has also gotten quite long in the tooth. Can you update to CentOS 7?
