Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:
> 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.
Exactly.
> 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.
Yup. And you didn't say so, but this meta-information is supposed to
be transparent to the "patch" program (as I believe it is). Someday
we may have a more parseable format, and a patcher that can actually
do something with it.
> 3. The output of 'svn diff' will be identical (ignoring ordering)
> regardless of whether the subtrees are in a working copy or repository.
Yup.
> 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.
I think you pretty much nailed it above.
> 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).
>
> We test for this behaviour explicitly in diff_tests.py (22: diff a file
> that has been renamed), but I can't understand why it's desirable.
I believe it was a deliberate decision (I'm not saying it's right,
merely that it was deliberate). It's desirable because people reading
diffs are often more interested in the changes made against the copy
source, changes which would be obscured if we simply showed the entire
copy as an add.
What we need, I think, is an option that causes adds to shown as full
adds (i.e., every line added), so at least one can get the formally
correct -- if less useful to humans -- behavior.
It's worth noting that on similar grounds, we already have the
--no-diff-deleted option to 'svn diff'.
> There are several reasons why it's _not_ desirable:
>
> * The result of 'svn diff' changes once you commit, because repos->repos
> diffs do _not_ have this behaviour (they report an add-with-history just
> the same way as an add: as the complete contents of the file, added).
That seems inconsistent; I wonder if it's an oversight, hmmm.
> * The result of 'svn diff' is no longer something that you can feed
> into patch. While copies (and property modifications, for that matter)
> can't be represented precisely as diffs, we lose even the fact that the
> file was created.
Agreed. This is a disadvantage.
> * The file shows up in 'svn status', but not 'svn diff'.
Yup. I think this was discussed during the decision, in fact.
> * It leads to the utterly weird situation whereby 'svn mv A B; svn diff'
> reports the deletion of A, but not the addition of B.
Well, there's --no-diff-deleted, but yeah. (Though I think the
deletion might still be reported even then, just not shown as a full
diff.)
> The _only_ advantage I can see for this behaviour is that it permits you
> to see what local modifications have been performed to the file since it
> was copied, if any. But I'm fairly sure that if you wanted to know that,
> you could pass in the old and new targets explicitly: it shouldn't be
> the default.
>
> So, two questions: Firstly, am I missing something? If not, do we really
> want svn diff to behave like this?
I don't think you're missing anything.
I do think we want this behavior. But, I don't know if we want it as
the default...
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 05:33:14 2005