[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn log" options and semantics

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-10-23 16:58:05 CEST

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.

> "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}.

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.
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".

> "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.

> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 16:59:18 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.