[Issue 1213] PREVx for specifying 'target at N changes ago'

[Erik Huelsmann <eh...@gmail.com>]

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?
- The change makes a new behaviour available, not only to the cli, but
also to libsvn_client. Do we want that?
- 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?

Thanks for any answers/opinions.

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 1213] PREVx for specifying 'target at N changes ago'

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand