Here's the mission, should you choose to accept it: Answer the question, "What was the last place that the line of history identified by PATH@REV was copied from, if any?" in the most efficient way. Options today: 1. Use svn_ra_get_log() to do a full history crawl of PATH@REV, and remember the most recent copy operation's source. The cost of this approach is directly proportional to the number of changes made to PATH@REV -- the entirety of that item's history. 2. Same #1, but bail out of the log processing as soon as you have your answer. Cost here is the same with #1, except you reduce some client-side processing of the logs which predate that most recent copy (if any). Server cost is the same. 3. Use svn_ra_get_location_segments() to get a summary of the locations this line of history has occupied over time. The cost here is completely variable. At best, the server is of 1.5 or better pedigree with a fully populated node origins cache, and returns the answer ("no copies") very quickly. At worst there are no copies in the item's history and the server is pre-1.5 and has to basically do the same full history crawl that get_logs() does in order to answer the question. In between are scenarios where the server can get the location segments fairly quickly but the client has to then figure out if those location changes were due to the item itself being copied, or because some parent of it was. 4. An incremental version of one or more of the above, trying to fetch history in chunks to avoid over-processing. Cost here could be an improvement, or could not. And code complexity grows. svn_client__get_copy_source() today goes with option #1. I think, though, that as we come to rely more on our server for complex information, we need to be less shy about giving the server the power to answer complex questions. I'd suggest at *least* an svn_ra_get_copy_source() API, but am open to other ideas (like a tunneled version of the svn_fs_history* interfaces, or an RA version of svn_fs_closest_copy(), or *something*).