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

Re: Peg revisions, diff, and repository roots

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-02-01 02:24:53 CET

On 1/31/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 1/31/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > > Consistency with other commands. That's the party line, at least. :-)
> >
> > /me still fails to see why defaulting to HEAD makes sense for the
> > other commands anyway...
> Ah! The history of pegrevs! It all started with this use-case:
> $ svn cat -rN foo.c
> svn: error: foo.c doesn't exist in rN
> // user curses
> $ svn ls -rN URL
> svn:error: URL doesn't exist in rN
> // user curses even more.
> $ svn log -v
> [user visually parses lots of junk, figures out old name]
> $ svn ls -rN slighty-older-URL
> [command works]
> [user sends angry mail to list saying "why don't you trace history?!?"]
> So we decided: OK, fine. If the user *ever* leaves off the @REV
> syntax on a path or URL argument, then it's our job to trace that path
> back in time. We assume that 'path' really means 'path@BASE' and
> 'URL' really means 'URL@HEAD'.
> We began by adding this peg-behavior to 'cat' and 'ls', and from there
> it slowly spread to the other commands. It may be slightly
> inconvenient (i.e. not optimized for the most common use-case in each
> command), but the theory is that at least the behavior is
> consistent... and thus predictable, easy to learn, easy to understand.

And yet, every time I have to deal with pegrevs I get a headache...

The problem, at least in this case, is that our policy of following
peg revisions is terribly, painfully, horribly slow when presented
with a repository of significant size. Like, lets go get a cup of
coffee and perhaps go purchase a new home, maybe it'll be done when we
get back.

It just seems like we should be going out of our way to make sure our
users have trouble entering commands that seem simple at first glance
but actually take a huge amount of time to complete.

> > Sure, but it seems like this history trace code should be able to say
> > "duh, this is the root node, it's never going to move!" and bail early
> > or something... And even the client side could check for the repos
> > root URL and bail early if we wanted to, although I'm not sure a round
> > trip is worth it.
> Yeah, actually, the WC is now storing the repository root url in the
> entries file. So I guess it would work!

I'll look into this...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 1 02:25:12 2006

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