You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2003/10/23 14:30:29 UTC
"svn log" options and semantics
1.
"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. In other words, operate in "incremental" mode all the time. This would have minimal impact on the prettiness of the display (and there are more serious pretiness concerns than this), and would obviate the need for that option.
2.
"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.
Alternatively we could make it more consistent (but not incremental) by evaluating the dates with respect to the specified item(s) rather than the whole repository.
3.
"svn log" crosses copy history by default; "--strict" disables this. "--strict" is far too vague a name, in the same way that "--force" is. 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."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Ben Gollmer <be...@jatosoft.com>.
On Mon, 27 Oct 2003 10:21:23 -0600, "C. Michael Pilato" <cm...@collab.net>
wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> > 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.
I use the --xml option to add a revision history to some internal documentation.
When documents are published on the intranet, a script pulls the log in xml
format and adds it to the source doc, then the whole mess is XSLT'd to XHTML
1.0 Strict. It would be too bad if this ability went away, although I could
certainly work around it with some string mangling.
I've never used the --incremental option, though.
--
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Files <fi...@poetryunlimited.com>.
Julian Foad said:
> So you are using non-incremental mode if the user asks for information about
> only one item, and the incremental mode if multiple items. And then you are
> parsing the XML output into a form suitable for display to the user. Is this
> correct?
Dead on. :)
> If you are able to use the "incremental" form, that means you don't need the
> header and footer, so you could use the incremental form always. I could
> remove the non-incremental form and the "--incremental" option, and make
> incremental output the default. (I'm not saying yet that I will remove it,
> but just checking that that wouldn't be a problem for you.)
Hmm. Actually, looking back and comparing the content, the --incremental
option was a little on the confusing side to me, when I was first working with
it.
It's not really proper XML. Even though it *IS* an XML fragment.
I ended up having to mimic the header and footer when the --incremental option
was picked, so that the standard xml parsers would understand what they were
looking at and parse the log entries correctly.
So if anything *had* to disappear in the --xml option, it would be the
--incremental option in my opinion. But I would definitely want to keep the
--xml option.
I think the --incremental option has a purpose, when collecting a large number
of fragments of log entries. But I don't think it makes that much of a hit for
my explorer.
It would be more useful to a statistical analysis tool which is still in the
minds of a few individuals on this list.
Your call - --incremental allows aggregation much faster than having to look
for the header and footer for every entry.
I vote we keep it for now, before we shoot ourselves in the foot by removing
it too soon.
> information, or _add_ information that is not being output by "svn log" at the
Add - you're right. Reduction is a no-brainer.
More specifically, I'm thinking aobut a standardized vocabulary of items that
can be handed out w/ the log request.
Eventually making the log and info functions almost the same, where info is
just a specific formatting option of log.
Or better yet a 'query' command that is a superset of both log and info where
log and info are formatting options....
Am I making any sense here???
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Julian Foad <ju...@btopenworld.com>.
Files wrote:
>>Do you use it in complete mode or --incremental mode?
>
> Actually, it's at the user's discretion - it's a repository explorer.
>
> So the short answer is both complete and incremental.
So you are using non-incremental mode if the user asks for information about only one item, and the incremental mode if multiple items. And then you are parsing the XML output into a form suitable for display to the user. Is this correct?
If you are able to use the "incremental" form, that means you don't need the header and footer, so you could use the incremental form always. I could remove the non-incremental form and the "--incremental" option, and make incremental output the default. (I'm not saying yet that I will remove it, but just checking that that wouldn't be a problem for you.)
>>>And here I thought it was so kewl that we even had the option. Now if we
>>>could
>>>only control what got spit out from the --xml option, I'd be set for life.
>>
>>I won't get rid of XML mode.
>
> THANK YOU! :-)
>
> Now if you could only tell me what kind of script-fu-magic to work to get the
> xml output customizable in terms of what information is output.....or is that
> too much of a magic cookie for the time being? :-)
That depends on whether you want to selectively _remove_ parts of the information, or _add_ information that is not being output by "svn log" at the moment.
Reducing the information can be done externally with standard XML tools. It would also be possible to add information selection options to the "svn log" command, applied to the plain text mode as well as the XML mode, but I am not convinced that it would be useful enough to justify the extra maintenance cost. (That is, I am not convinced that that feature is a Good Think over all.)
If you are processing the output anyway, I don't see why it is useful to have some of the information already removed. The only thing I can think of is efficiency, if some of the information is large and not wanted. That is why the "-v" and "-q" options exist. Oh...
BUG: "svn log --quiet --xml" still outputs the log message text. "-q" is supposed to suppress that part. I'll take a look at that.
Increasing the information obviously requires changes to the "svn log" command.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Files <fi...@poetryunlimited.com>.
> Do you use it in complete mode or --incremental mode?
Actually, it's at the user's discretion - it's a repository explorer.
So the short answer is both complete and incremental.
>> And here I thought it was so kewl that we even had the option. Now if we
>> could
>> only control what got spit out from the --xml option, I'd be set for life.
>
> I won't get rid of XML mode.
THANK YOU! :-)
Now if you could only tell me what kind of script-fu-magic to work to get the
xml output customizable in terms of what information is output.....or is that
too much of a magic cookie for the time being? :-)
--
Shamim Islam
BA BS
>
> - Julian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Julian Foad <ju...@btopenworld.com>.
Files wrote:
> kfogel@collab.net said:
>
>>"C. Michael Pilato" <cm...@collab.net> writes:
>>
>>>IMO, we should stop printing the trailing separators in non-XML log,
>>>and ditch the --incremental option. Then, either ditch the --xml
>>
>>By the way, I think people *are* using the --xml option... but I
>>haven't any evidence to back that up.
>
> I use the --xml option in the log for my subversion explorer. If you remove
> this, I will be forced to remunge the output. *sigh* lol
Do you use it in complete mode or --incremental mode?
> And here I thought it was so kewl that we even had the option. Now if we could
> only control what got spit out from the --xml option, I'd be set for life.
I won't get rid of XML mode.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Files <fi...@poetryunlimited.com>.
kfogel@collab.net said:
> "C. Michael Pilato" <cm...@collab.net> writes:
>> IMO, we should stop printing the trailing separators in non-XML log,
>> and ditch the --incremental option. Then, either ditch the --xml
>
> By the way, I think people *are* using the --xml option... but I
> haven't any evidence to back that up.
I use the --xml option in the log for my subversion explorer. If you remove
this, I will be forced to remunge the output. *sigh* lol
And here I thought it was so kewl that we even had the option. Now if we could
only control what got spit out from the --xml option, I'd be set for life.
When it rains it pours? :)
--
Shamim Islam
BA BS
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> 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.
The --incremental option was added, if I recall correctly, mainly to
support concatenation of non-xml log output.
I'd be fine with ditching the option, if the leading separator were
removed. (It's better to remove leading than trailing, since some
parsers ignore the line count and just depend on finding a terminating
separator for each log message -- including some of our own in tools/,
which we'll have to fix, but that's no big deal).
By the way, I think people *are* using the --xml option... but I
haven't any evidence to back that up.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Julian Foad <ju...@btopenworld.com>.
Arild Fines wrote:
> On Mon, 2003-10-27 at 17:21, C. Michael Pilato wrote:
>
>>Julian Foad <ju...@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?
>
> Draco .NET[*] relies on svn log --xml to parse log output. Please don't
> remove it.
Is it using incremental or non-incremental mode, or both?
- Julian
> [*] http://draconet.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by Arild Fines <ar...@broadpark.no>.
On Mon, 2003-10-27 at 17:21, C. Michael Pilato wrote:
> Julian Foad <ju...@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?
Draco .NET[*] relies on svn log --xml to parse log output. Please don't
remove it.
[*] http://draconet.sf.net
--
Arild
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad <ju...@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
Re: "svn log" options and semantics
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Julian Foad <ju...@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
Re: "svn log" options and semantics
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
On 23 Oct 2003 09:58:05 -0500, "C. Michael Pilato" <cm...@collab.net>
said:
> Julian Foad <ju...@btopenworld.com> writes:
>
[snip]
>
> > "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.
>
What about --ignore-copies or --ignore-copy ?
Bye !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn log" options and semantics
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad <ju...@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