Mark Phippard wrote:
> On Fri, Jun 6, 2008 at 11:55 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> Vincent Lefevre <vincent+svn_at_vinc17.org> writes:
>>> The status of affected paths output by "svn log -v" has one column
>>> only, contrary to "svn status", which uses two columns: one for the
>>> contents and one for the properties. Is the behavior of "svn log -v"
>>> intentional? Wouldn't it be better to distinguish contents and
>>> properties in "svn log -v" output too?
>>> FYI, I could only find this reference about affected paths:
>> The decision not to reflect that difference was deliberate, as log is
>> just a summary of what changed. We haven't heard a lot of clamoring for
>> it to distinguish, so I'm not sure there's a pressing need to change
>> it... (not even getting into compatibility concerns).
> I recall this coming up after 1.0 and something about the way this was
> implemented would require a 2.0 to change. I am not sure how true
> that is given some of the other changes we have managed to make since
> then. I am pretty sure this information is not transmitted from the
> server to client currently though, so it is not a trivial matter to
> just add it.
Oops -- I mispoke earlier when I said that this information already
available in the log structures. What you get today is just "props
were/weren't changed", not the full added/modified/deleted status for
Another thing folks have asked for often (and I personally would love to
see) is the change to have log's changed-paths carry a `kind' field (file,
directory, etc.). That is something we don't store with the changes in the
repositories, and, while easy to calculate at log-time, adds expense. And,
of course, the wire formats would need to be adjusted, as would the
svn_log_path_changed_t (unless we suddenly started allowing directories to
carry trailing slashes as a "kind" flag).
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-06-06 18:28:56 CEST