Hello list,
I'm hoping that someone can explain to me what output 'svn diff' is
supposed to produce.
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.
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.
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.
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).
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.
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).
* 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.
* The file shows up in 'svn status', but not 'svn diff'.
* 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.
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?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 01:17:45 2005