On Thu, 2004-04-01 at 07:54, Branko Cibej wrote:
> Quoting Greg Hudson <ghudson@MIT.EDU>:
> > We discussed this in the earlier (pre-1.0) thread. Consensus was that
> > we can't trace into the future across renames of the file or its
> > parent directories (because all copies look the same, whether or not they
> > were renames, and even if there's only one copy of the same node in the
> > target rev, it's too hard to find given the current FS schema), but we
> > can check if <future-rev,path> is the same node-copy, and use that if so.
>
> Yes I know the current schema doesn't support the forward search, but the _API_
> should allow it.
I feel like we're getting ahead of ourselves here. I've been working on
cmpilato's patch for a day or so, which deals with the exact same
issue/API, but it's client-side function. I'm posting the
patch-in-progress below for people to examine, because I think it should
have been seen first, before Shlomi's server-side stuff. The theory is
that once we get subcommands using the new client history function, we
can switch the function from running RA->get_logs to
RA->some_new_fs_history_routine(). Back up a minute here.
Mike's new client routine *does* allow future searching... at least, the
API doesn't forbid it. It takes a (rev, path) pair as a "peg" for a
line of history, and then two revisions X and Y that make up a range to
search. The function potentially returns both (X, old-path-location)
and (Y, future-path-location).
The reason I've not yet committed this patch is because I'm precisely
bumping up against this wall of "searching into the future". That is,
I've taught 'svn cat -rX foo.c' to use the new client history function
pre-emptively: it uses (BASE, foo.c) as the peg, and passes X as the
"start" of the range to search, with an unspecified end range.
However, in trans-test.py #8, BASE of foo.c happens to be 3, and HEAD is
5. When the test runs 'svn cat -rHEAD foo.c', Mike's history function
throws an error. It tries running RA->get_logs() on (3, foo.c), but
never finds the path in 5 (duh), and throws an error.
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.")
I'm much more inclined to go the second route for now, because it's much
simpler. The first approach seems nice in an academic way, but I doubt
it will be truly useful to users. Users will see *some* error: either
"sorry, foo.c in the future isn't the same foo.c you have now!", or
"sorry, can't look into the future." Either way, they're going to have
to work around the problem by using the URL.
Here's the log message + attached patch-in-progress:
-------------------------------------------------
A patch (mostly) from Mike Pilato: major step towards solving issue
#1093 -- "svn diff (and other subcommands) do not notice rename/copies."
This implements a new function which takes a revision range and a
(rev, path) pair as input (the "peg" for defining a line of history),
and returns new (rev, path) pairs at either end of the range.
As a proof of concept, 'svn cat -rN wcpath' now follows copy history
backwards in time.
* subversion/include/svn_client.h
(svn_client_repos_locations): New.
* subversion/libsvn_client/client.h
(svn_client__prev_log_path): New.
* subversion/libsvn_client/ra.c
(struct log_message_baton, svn_client__prev_log_path, log_receiver,
svn_client_repos_locations): New.
* subversion/libsvn_client/cat.c
(svn_client_cat): make 'svn cat' use the new history-finding
function whenever invoked on a wc-path, but never on a URL.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 17:56:19 2004