Merge information in ls OR "svn ls -v -g"

[James Hanley]

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.

-Jim

[Rp0013]

We migrated to subversion 1.7.2 today from 1.4.6 and seeing sudden issues with memory

The free memory drops suddenly (24g memory on the box) 

We have upgraded only the server and clients are various versions 1.4.6 1.4.2 1.6.9 etc

I saw some mention of memory leaks but this seems like a major issue

 

We are using 

Red hat 5

Apache 2.2

Neon 0.29.6

Apr 1.4.5

Apr util 1.3.12

Surf 1.0.0

Any help or suggestions would be greatly appreciated.

Regard,

Rajesh

Sent from my iPad 

 

[Nico Kadel-Garcia]

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!)

 

[Daniel Shahaf]

http://subversion.apache.org/docs/community-guide/mailing-lists.html#fresh-post

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

[James Hanley]

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.

[Mark Phippard]

On Wed, May 9, 2012 at 9:08 AM, James Hanley <jha...@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.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/