* email@example.com <firstname.lastname@example.org> [2004-07-03 14:25]:
> Michael W Thelen <email@example.com> writes:
> > But speaking of elegance... both special case (a) and (b) seem to be
> > made necessary by the fact that we default to HEAD:1 and BASE:1 instead
> > of HEAD:0 and BASE:0 when the user passes no arguments to "svn log".
> > While writing the patch, I thought it would have been much nicer if we
> > could just pass HEAD:0 to ra_lib->get_log and have it "do the right
> > thing". That is, produce an r0 log message when the start and end
> > revisions requested are both 0, but don't tack an r0 log message on the
> > end otherwise.
> It's hard to imagine a circumstance under which the r0 logs could be
> relevant to anyone, since no user created r0. And the behavior
> proposed above is... Well, let's just say I had to read it three times
> myself, and I was already thinking hard about the issue :-). Do you
> really want to have to document that behavior for users?
Sorry, I don't think I made myself very clear. I agree, no one really
wants an r0 log message, unless they explicitly request it with -r0 or
-r0:0. My suggestion was that ra_lib->get_log's behavior could be
changed so that it never produces an r0 log message except when
requested in this way.
So requesting -r5:0, for example, would only produce log messages for r5
down through r1. Currently, requesting -r5:0 produces log messages for
r5 through r1, plus a "No commit for revision 0" message. That's the
only change to ra_lib->get_log that I'm proposing.
If this behavior were put in place, we could easily make both special
cases (a) and (b) go away by changing the default requests from
HEAD:1/BASE:1 to HEAD:0/BASE:0:
(a) The repository has 0 revisions and the user runs "svn log URL".
Currently this is translated to HEAD:1 (0:1), which will produce an
error because r1 doesn't exist. If it were translated to HEAD:0
(0:0), only a "No commit for revision 0" message would be produced.
(b) The working copy is at BASE revision 0 but the repository is not empty,
and the user runs "svn log" in the working copy. Currently this is
translated to BASE:1 (0:1), which will produce an r1 log message
even though the working copy is only at revision 0. If it were
translated to BASE:0 (0:0), only a "No commit for revision 0"
message would be produced.
> (IOW, I'm punting on the question of interface compatibility, because
> even if this were compatible, I don't think we'd want to do it.)
> I think r1 is a good default for almost all cases. In the rare times
> when it's not, we can notice the problem, and handle the special case.
That's a fine solution, too. I just thought that the client code would
be simpler without having to catch these special cases. Making the
proposed change should only break client code that is relying on a "No
commit for revision 0" message when requesting a range including r0,
like -r5:0. I would doubt that anyone does this, but I don't know.
Anyway, this discussion is a bit separate from the actual patch. In a
little while I'll send a new patch containing what you suggested: only
the (b) special case handling, with the other changes removed.
Michael W. Thelen
Continued dependence upon relief induces a spiritual and moral disintegration
fundamentally destructive to the national fibre. To dole out relief in this
way is to administer a narcotic, a subtle destroyer of the human spirit.
-- Franklin Delano Roosevelt
Received on Sat Jul 3 23:25:51 2004