On Thu, 2004-04-01 at 13:26, Ben Collins-Sussman wrote:
> On Thu, 2004-04-01 at 11:34, Greg Hudson wrote:
> > On Thu, 2004-04-01 at 10:55, Ben Collins-Sussman wrote:
> > > There are two approaches here:
> > >
> > > 1. as ghudson suggests, run RA->get_logs() on (5, foo.c), and verify
> > > that the (3, foo.c) is actually the same object.
> > >
> > > 2. throw a specific error ("future searching not yet implemented"),
> > > so that callers can catch the error and make a helpful suggestion ("try
> > > running 'svn cat -rHEAD' on the URL instead of the working file.")
> >
> > Have you ever cd'd to your Subversion working directory and run "svn log
> > -r HEAD"? Do you really want to break that?
>
> I think 'svn log' is a bad example here, because that's the one
> subcommand that *does* follow history already.
No, log is a fine example. It currently follows history while searching
backwards, but it doesn't follow history when deciding what node-rev to
start searching from. Try it:
cd your-svn-working-dir/subversion/libsvn_fs/notes
svn log structure # Note history going back to r1
svn log -r155 structure
> And how far does your argument go? Are you suggesting that until we
> change the fs schema to make future-searching possible, we shouldn't add
> the past-searching feature to any subcommand? Are bunches of behaviors
> going to break that I'm not considering?
I'm saying we should do the optimistic-future-searching thing mentioned
in (1) above, when presented with a future operative revision. How are
we miscommunicating?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 21:17:25 2004