Julian Foad <julianfoad@btopenworld.com> writes:
> 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.
Does anyone actually use the XML form of this function's output?
IMO, we should stop printing the trailing separators in non-XML log,
and ditch the --incremental option. Then, either ditch the --xml
mode, or simply explain that isn't suitable for concatenation across
runs.
> Do I have any company in this line of thinking?
Perhaps, but I find myself not prioritizing this very highly. As long
as we are consistent in our treatment (re: "inclusive"
vs. "non-inclusive") of revision numbers, and we document the way a
date-to-revision conversion happens, we should be fine. As you noted,
yes, doing a DATE+1 isn't perfect because no matter how small a unit
that "1" applies to (days, minutes, seconds, whatever) we can in
theory have multiple revisions between DATE and DATE+1. But that's
not true of revisions. So if precision is what you need, use the
revision form of the -r option.
> >>"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.
Actually, both --no-copies and --ignore-copies are wrong, because they
imply only that copies will be skipped. That's not what really
happens. It should be something more like --stop-on-copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 27 17:22:43 2003