I'm raising the issue that there should be an option to include merge
information of an "ls -v" in much the same way that "svn blame"
supports it. Although, I can easily use "svn blame -g" to find out who
/originally/ added a file, it's not intuitive, the more natural method
(IMHO) is to use "svn ls -v -g" to give the info on who originally
added/modified a file, not necessarily the last to merge the new file.
Essentially, I'm looking for merge history blame on a path structure
in the same way that I can get merge history blame on an individual
file contents.
On Tue, May 1, 2012 at 1:09 AM, Rp0013 <rp0...@gmail.com> wrote:
> We migrated to subversion 1.7.2 today from 1.4.6 and seeing sudden issues
> with memory
> You're using a hand built version? Grab the SRPM from Repoforge, I mostly
wrote and submitted the last few, and the latest patches and spec files are
actually in the pipeline for a new update are at
http://www.github.com/nkadel/ for both 1.7.4 and 1.6.18, both of which now
build on RHEL 4. (Moo-ha-ha!)
It would be useful to know what backend you use (FSFS or BDB), what
authn and authz configuration you have, and what is the minimal httpd
config that still reproduces the leak.
Daniel
Rp0013 wrote on Mon, Apr 30, 2012 at 22:09:59 -0700:
There's no interest/descending/rebuttal opinion to this? Should I
create a enhancement ticket? I thought that this was the medium to
first propose changes/enhancements for discussion.
On Mon, Apr 30, 2012 at 4:16 PM, James Hanley <jhan...@dgtlrift.com> wrote:
> All,
> I'm raising the issue that there should be an option to include merge
> information of an "ls -v" in much the same way that "svn blame"
> supports it. Although, I can easily use "svn blame -g" to find out who
> /originally/ added a file, it's not intuitive, the more natural method
> (IMHO) is to use "svn ls -v -g" to give the info on who originally
> added/modified a file, not necessarily the last to merge the new file.
> Essentially, I'm looking for merge history blame on a path structure
> in the same way that I can get merge history blame on an individual
> file contents.
On Wed, May 9, 2012 at 9:08 AM, James Hanley <jhan...@dgtlrift.com> wrote:
> There's no interest/descending/rebuttal opinion to this? Should I
> create a enhancement ticket? I thought that this was the medium to
> first propose changes/enhancements for discussion.
My 2 cents would be that I do not see the need or value. The ls
command is only showing a single version of each path, I do not see
how you could show merge info. If you want to see the history of a
path, then use the svn log -g command.
> I'm raising the issue that there should be an option to include merge
> information of an "ls -v" in much the same way that "svn blame"
> supports it. Although, I can easily use "svn blame -g" to find out who
> /originally/ added a file, it's not intuitive, the more natural method
> (IMHO) is to use "svn ls -v -g" to give the info on who originally
> added/modified a file, not necessarily the last to merge the new file.
What if the most recent change to the file was a regular commit, but
the previous change was the merge? What if the last change was the
commit of a merge but there were 4 different revisions by 4 different
authors. I do not see how ls is supposed to represent that.
> Essentially, I'm looking for merge history blame on a path structure
> in the same way that I can get merge history blame on an individual
> file contents.
The command to inspect the history of a path is svn log, not svn ls.
Add the -g option to log if you want to include merge information.
