Martin Hauner wrote:
> i created a partial patch for diff summarize, Issue 2015.
Thanks for the patch, but before we think about the code let's discuss the
requirements. This is the first I've heard of it.
Quoting from http://subversion.tigris.org/issues/show_bug.cgi?id=2015
> A "-s" ("--summarize") option should be added to the "svn diff"
Well, the short option name "-s" is perhaps not appropriate because this option
is specific to one svn subcommand. "-q/--quiet" might be appropriate if it was
going to behave like a cut-down version of "svn diff", but it seems that it is
not going to do so. So probably just a long option "--summarize".
> capability. This will reduce the output to a single line for each file
> or directory that has changed between two URL's. It should also work
> for two revisions and a single URL. For consistency, I imagine this
> would look similar to "svn status", but instead of operating on a
> working copy, it would operate on two revisions in the repository.
OK, I can see this being useful. The extreme approaches are to make the output
as much as possible like "svn diff" or "svn status" or "cvs diff -s"; in
practice it will probably have something in common with each of these.
"svn status" is already showing a summary of the difference between one
repository state and another (uncommitted) state. It would initially seem that
the exact same output format could apply to a diff between two states which are
each independently committed or uncommitted, just without some of the
possibilities that exist in a WC.
> Coupled with this should be "-q" ("--quiet") and "-v" ("--verbose")
> options to display additional information. Verbose output with "-s"
> should still only display a single line per file.
You don't say what "-q" should do. If it just means "not verbose" then there's
no need for it.
> I think the following information would be helpful to include in the output:
In the following I call the first target of "diff" its "left" target, and the
second target its "right". Often a diff is invoked with an old target for its
"left" argument and a newer version of the same thing for its "right" argument,
but not by any means always.
> * Whether the item is a file, directory, (or anything else?)
Certainly that would be nice, but I note that neither "svn diff" nor "svn
status" currently make this distinction.
> * Whether the change was a content or property change
Yes (either, both, or neither).
> * What was the revision prior to any changes
> * What was the revision after all changes
From the examples I see that you mean the revision in which the item had last
been changed at the versions identified by LEFT and RIGHT respectively.
Hmm. I don't particularly object to having this information, but it doesn't
feel to me like a logical part of the summary of the difference.
<a while later> I've now gone and read the discussion on the users list, where
it is pointed out that CVS diff has such a summarise facility, and these
revision numbers are the main information that it gives. So, OK, we probably
want to give these.
> * Who committed the last change
What, for LEFT or RIGHT or both? I assume you mean for RIGHT only, on the
assumption that that is often the newer version, with the possibility that that
will have been the only change made to the item. That information doesn't seem
a good fit for this feature. That information can be got from "svn list
--verbose RIGHT".
> So, how would this look? Roughly following the "svn status" syntax,
> here is a starting point:
> First column says if the item was added, deleted, or otherwise changed
> Second column determines if there were property changes
So far so good.
> Third column says if the item is a directory, or otherwise not a file
We have no precedent for that, though it's not necessarily bad.
> Remaining fields are variable width and delimited by spaces:
> (with -v) Last revision number prior to change
> (with -v) Last changed revision number
> (with -v) Author of last changed revision
If we have each of these, we should probably have it in exactly the same format
as "svn status".
> Path, relative to the given URLs.
That's good if LEFT and RIGHT are directories, but what if they point directly
to a file?
>
> $ svn diff -s http://repos/tags/rel1 http://repos/tags/rel2
> A /path/to/file1
> MM /path/to/file2
> A D /path/to/a_new_dir
> D /path/to/file3
>
> $ svn diff -s -v http://repos/tags/rel1 http://repos/tags/rel2
> A 120 145 bob /path/to/file1
> MM 100 111 joe /path/to/file2
> A D 120 120 jane /path/to/a_new_dir
> 80 80 bob /path/to/unchanged_file
> D 101 130 bob /path/to/file3
>
> Notes:
> The -v option should list ALL files in either tag.
So it alters both the information that is shown for each item and the set of
items that are displayed, like it does in "svn status"? I don't like that
much, though since we have it in "status" I might tolerate it.
Possibly we won't need a brief form of the information shown for a particular
item ... I don't know.
> The extra -v information columns are padded with spaces in the same manner as
> "svn status -v".
OK.
> "last revision prior to change" for newly added files should be the
> revision in which it was added. One should be able to checkout the
> first listed revision of all the files (that don't have an "A" in the
> first column) and get rel1.
That's self-contradictory if you mean the LEFT revision. The LEFT revision
number field should specify a revision BEFORE the file was added, such as zero
or (the revision number of rel1), or be blank.
> Similarly, "last changed revision"
> for deleted files should be the revision in which it was deleted.
That sounds reasonable, though not the only possibility.
> Checking out the 2nd listed revision of all files (without a "D" in the
> first column) should be equivalent to checking out rel2.
Yes; this should work even if one tries to include those with a "D" in the
first column.
Well, those are my comments on what is written in the issue. I haven't yet
thought about it from the direction of trying to summarise "svn diff" or
generalise "svn status" myself.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 3 18:56:49 2005