The "follow copy history" initiative

I wanted to let everyone know about my initiative to make svn
subcommands aware of copy history. For example, if I run

  svn cat -r100 foo.c

...and foo.c was at a different URL in r100, svn should autotmatically
be able to follow that copy/rename history and still show us the proper
file. At the moment, we get an error about how foo.c's path "doesn't
exist in r100".

This problem is endemic to a bunch of subcommands: cat, ls, blame,
diff, merge, and maybe others. It's irritating our users to no end.
Issue #1093 is the current focal point for this class of bugs.

I see three phases to fixing the problem:

1. write an internal client function which, given a "peg" (rev, path)
coordinate pair, is able to find the same object at a different path in
an earlier revision.

2. make our subcommands use this new client function.

3. [optimization] make the server do the history searching, not the
client.

Step #1 is mostly done: Mike Pilato has written this function in the
current patch attached to issue #1093. I'm testing it now. It's doing
the "clumsy" thing by calling RA->get_logs() to collect history.

Step #2 is yet to be done. For some subcommands (like 'cat' or 'ls'),
the upgrade will be easy, no UI changes required. IIRC, we might need
to have some UI discussions about upgrading diff/merge, due to possible
amibiguities. Don't wanna go there yet, though. :-)

Step #3 is something that Shlomi Fish is interested in working on,
possibly on a branch. The idea is that we add a new RA function to the
bottom of our RA vtable (so as to be 1.1 compliant) which asks the
*repository* to do the history search using the fs_history API. That
way the client gets back a single targeted answer, rather than sloughing
through hundreds of logs. Once the new RA function exists, we upgrade
the new client function (created in step #1) to use it instead of
RA->get_logs().

That's the overview. Anyone see any horrible problems here?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 19:46:58 2004