Besides complexity and performance hits?
For 'svn log', the client doesn't know the node kinds of changed files (as
the server doesn't report as much). For 'svn diff --summarize' (and similar
editor-based operations), the client knows the node kind most of the time,
but our editor's delete_entry() call is kind-agnostic, whichs means that any
time your deletion isn't of a working copy item (for which you could stat()
the kind), you'd have to make more network turnarounds to know whether a
given deleted thing was a file or directory.
Jeremy Whitlock wrote:
> Do you know of anything in place that would keep me from
> submitting such a patch?
> Take care,
> On 10/15/07, David Glasser <firstname.lastname@example.org> wrote:
>> On 10/15/07, Mark Phippard <email@example.com> wrote:
>>> On 10/15/07, Jeremy Whitlock <firstname.lastname@example.org> wrote:
>>>> If other subcommands are affected by this, I would propose that we
>>>> fix them all then. Not knowing whether an outputted path is a file or
>>>> directory can be a pain to find the answer to usually requiring a
>>>> server round trip. From a scripting perspective, this is problematic.
>>>> I agree with consistency so I understand that if agreed upon, my
>>>> patch would have to potentially touch many subcommands but in the end,
>>>> I think having a visible way to distinguish file path from directory
>>>> path would be a great update to Subversion's output.
>>> I don't really disagree, but I do not think we can change the format
>>> of our output until 2.0. I believe it is part of the compatibility
>>> rules for the API. I could be wrong, but I think I have heard that
>> At the very least we could add a kind="dir"/"file" attribute to the
>> log --xml output. I'd apply a patch for that. (Also, diff
>> --summarize --xml would be pretty straightforward to implement.)
>> David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Oct 16 00:15:38 2007