Malcolm Rowe wrote:
>
> I'm hoping that someone can explain to me what output 'svn diff' is
> supposed to produce.
Thank you _very_ much for asking. We sorely need this defined and the bugs and
quirks in "diff" ironed out.
> That's not as stupid a question as it sounds - I've looked around at the
> book, the API documentation, and the help, and although they describe
> it in general terms, the specifics are absent.
>
> So here's my attempt at a definition of the _basic_ functionality,
> ignoring --notice-ancestry and --no-diff-deleted: (and note that while
> the actual client command has three syntax variations, they can all be
> implemented using the following)
>
> 1. 'svn diff' accepts two path/revision pairs, each representing a
> subtree of a repository or working copy at a particular revision (or
> BASE or WORKING for the wc). The output of 'svn diff' is something that,
> when fed to GNU patch, will convert the first tree into the second tree.
Patch: not exactly; you need to say something about how only the modifications
to individual files are obeyed by Patch, and whether this should include
whole-file deletes that are part of a whole-subtree delete.
Also I should think we ought to say explicitly that tree-change information
should be included in the output in an unambiguous form that might be usable by
a hypothetical tree-aware Patch program, and can certainly be used by a human.
> 2. The output also contains textual comments that describe directory and
> file property modifications, except for deleted files or directories,
> where property deletions are implicit.
>
> 3. The output of 'svn diff' will be identical (ignoring ordering)
> regardless of whether the subtrees are in a working copy or repository.
And something about what the same diff in reverse order should look like.
And, when we put this specification into more detail, something about how the
files and revisions are labeled. In particular, what revision number or "base"
or "wc"-type label is appended to a file name in various circumstances.
> Sounds good? We don't do that, of course, but most of the reasons why
> are bugs.
>
> The reason why I'd like a definition is that I'm spending some time
> looking at the diff code at the moment. It's pretty complex already,
> and it's even harder to understand when we don't seem to have a design
> spec for the feature.
Here, here!
> Also:
>
> There _is_ one place where we deliberately don't follow the text above,
> and I'd also like to understand whether it's the result of a deliberate
> design decision, or whether it's a bug that's been codified into
> a feature.
>
> Here it is:
> For BASE->WORKING and repos->WORKING diffs, we do not show a new copied
> (i.e. schedule-add-with-history) file as 'added' in the output of 'svn
> diff'. Regardless of the requested revision, for these files, we show only
> local modifications (that is, any modifications made _after_ the copy).
As others have commented, a re-think and proper design of this behaviour would
be good. Of course we have backward compatibility guarantees, but let that not
stop us from designing the best long-term solution first and then seeing what
we are allowed to do towards it in the short term.
Hooray for you, Malcolm!
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 14:56:43 2005