Erik Huelsmann wrote:
> In the issue tracker there's a patch sitting around which allows to
> specify from the command line client, instead of PREV, PREVx where x >
> 1.
>
> The patch could be optimized with our log --limit behaviour nowadays,
> but I'm more interested in discussing a few related questions:
>
> - Do we still want this change?
Seems cool, but I don't really see a strong use-case for it.
> - The change makes a new behaviour available, not only to the cli, but
> also to libsvn_client. Do we want that?
If we'd want it for the cli, I should think we'd want it for all clients.
But the API support would need to be sane. I mean, I wouldn't want to see
libsvn_client parsing "PREV54" strings or anything.
> - The patch uses svn_ra_get_log() to resolve the 'N changes' to a real
> revision number. That is the best/only way to do this, right?
Yes. But it has some gotchas that I haven't look through to patch for. I
mean, 'svn log' shows (and counts) as a change to a file any revisions in
which parent directories of the file were copied. It makes sense for an
option like --limit 5 to include that, because you are really limiting the
output of the command, not trying to calculate a spot in a line of history
like PREVx does. So, the PREVx code would need to *not* count those types
of revisions (unless they also contained real changes to the object in
question). This, of course, complicates the --limit optimization, because
then "PREV5" may not be fulfilled with a log limited to 5 items. Still, you
could fetch the first x logs first, and then if you can't fulfill the
request, go back and fetch the rest of the logs items or x more or something.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Mar 26 05:49:17 2007