Re: "svn log" options and semantics

C. Michael Pilato wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>"svn log" prints a row of dashes before each log message, and after
>>the last one. There is an option "--incremental" which suppresses
>>the final row of dashes. This is a trivial thing to have an option
>>for. I think it would be better to have a row of dashes either
>>before or after each message, but not both.
>
> Hm... operating in incremental mode by default means that when you use
> the --xml option, the default output is not well-formed.

Oh, I had forgotten about the XML output. It appears that this option was primarily intended to control the XML output, and suppressing the extra row of dashes is just a secondary nicety. (In the book there is an example about a page long of using "--incremental" to remove a row of dashes; that's over the top.)

Perhaps this mode (as applied to XML output) could be better described as "bare". After all, these blocks of XML are not "incremental" in the sense that you can append them to an existing "svn log --xml" document ... unless we provide "--xml-header" and "--xml-footer" functions to start and finish the document.

My reason for criticising this feature is that I think the word "incremental" better describes a mode which allows incremental revision (or date) ranges without overlap between the end of one range and the beginning of the next, as discussed below.

>>"svn log -rX:Y" prints the logs from the repository* revision at or
>>before X up to the revision at or before Y, inclusive. (* Not the
>>item's revision at or before X, which can be different when X is a
>>date.) That means that, when specified by date, a revision before
>>the requested period may be displayed as well, depending on what the
>>revision history was in other parts of the repository before the
>>specified start date.
>>
>> ~/tmp/svn-sandbox> svn log -q -r{2003-08-20}:{today} t
>> ------------------------------------------------------------------------
>> rev 17: julianfoad | 2003-08-15 02:17:06 +0100 (Fri, 15 Aug 2003)
>> ------------------------------------------------------------------------
>> rev 32: julianfoad | 2003-09-23 22:53:14 +0100 (Tue, 23 Sep 2003)
>> ------------------------------------------------------------------------
>> rev 33: julianfoad | 2003-09-23 22:54:51 +0100 (Tue, 23 Sep 2003)
>> ------------------------------------------------------------------------
>> ~/tmp/svn-sandbox> svn log -q -r{2003-09-20}:{today} t
>> ------------------------------------------------------------------------
>> rev 32: julianfoad | 2003-09-23 22:53:14 +0100 (Tue, 23 Sep 2003)
>> ------------------------------------------------------------------------
>> rev 33: julianfoad | 2003-09-23 22:54:51 +0100 (Tue, 23 Sep 2003)
>> ------------------------------------------------------------------------
>>
>>This is Badness. An "incremental" mode is required here, at least
>>as an option, and perhaps as the default. This mode would list the
>>changes that were made _between_ the two specified revisions (or
>>dates), rather than _in and between_ them.
>
> The problem, as you've described it, makes sense. I think your
> solution is off, though. You should always be able to achieve
> non-inclusiveness by turning -rX:Y into -rX+1:Y-1 (where X < Y). That
> means you can turn -r{2003-09-20}:{today} into
> -r{2003-09-21}:{yesterday}.

I don't know exactly what you mean. By "X+1" do you mean "+1 day" as your example seems to indicate, or "+1 revision number", or "+1 change of the item in question", or what? I can't see any way in which "-r{2003-09-20}:{today}" could be considered an "inclusive" equivalent of "-r{2003-09-21}:{yesterday}". They describe ranges that differ by a day at each end, and a day could contain any number of revisions or none.

> The problem, I think, is that our date-to-revision transformation
> doesn't seem to track the direction of your search. We do a
> date-to-revision conversion up front, which tends toward the youngest
> revision as of some date. But sometimes we want the oldest revision
> *after* some date, depending on how the -r arguments are arranged.

Yes, that sounds like part of a solution: to interpret a date as "First revision >= DATE" when it is the beginning of a range, but "Last revision < DATE" when it is the end of a range.

But that by itself is incompatible with the current "inclusive" model in which "svn log" describes the changes leading up to the revision that existed at the beginning of the range as well as changes that happened during the range. I think that it should describe only changes that happened _between_ the beginning and end of the range, just like "diff" does.

> In much the same way, sometimes you want "2003-08-20" to mean
> "2003-08-20:00:00:00", and sometimes you want "2003-08-20:23:59:59".

Only when you want "inclusive" operation. I do not want this "inclusive" interpretation when operating in "incremental" mode, but it would be convenient at other times.

Urgh. Much of this difficulty in defining how it ought to work hinges on the definition of "revision". We never did clarify and spell out the difference between "revision" meaning a tree-state, and "revision" meaning a process of revising.

When I specify revisions with "-r", I think I am specifying tree states. However, the information provided by "svn log" is all about the process of revising, and therein lies the confusion. We have implemented "svn log -r33" as meaning "show the changes between tree-state 32 and tree-state 33". Why have we done that? Well, because we are confusing "tell me about the 33rd tree state" with "tell me about the 33rd process of revising".

The way I see it is: The canonical invocation of "log" is "log -r32:33" shows the changes between tree-state 32 and tree-state 33. "log -rN" can be defined as shorthand for "log -rN-1:N" if we like, but I'd like to regard that as a convenience that should not affect the design decisions.

Do I have any company in this line of thinking?

>>"svn log" crosses copy history by default; "--strict" disables this.
>>"--strict" is far too vague a name, in the same way that "--force" is.
>
> Agreed. It should be '--no-copies' or something like that.

Yup, fine. "--ignore-copies", perhaps, as someone said.

>>How about "--ignore-ancestry"? That's based on my assumption that
>>"--notice-ancestry" means to cross copy history, but I'm not sure if
>>that is so. The only description I can find says "Pay attention to
>>ancestry when calculating differences."
>
> No, this has nothing to do with copies. Those are talking about
> ancestry between targets of a diff or merge.

OK.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 25 01:12:03 2003