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

Re: The "follow copy history" initiative

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-08 22:41:52 CEST

[ Sorry to break the thread here; I accidentally deleted the whole
thread from my mail app. ]

I've gone back and carefully re-read every mail in this thread, drawn
pictures on whiteboards, and discussed with cmpilato. I'd like to
proceed with ghudson's recommendation. After much thought, it seems
eminently sane to me now.

The roadmap is:

* for now, cmpilato's function will only verify that that the path in
rFUTURE is on the same line of history as our peg. If so, great. If
not, return an error about the rFUTURE object being unrelated.

* someday, when we're able to search forward in history, cmpilato's
function will only follow moves, and still return exactly one path from
rFUTURE. (or NULL/error if the object doesn't exist in rFUTURE.)

What's confusing the task (at this point) is that we're not talking
about one new function anymore, but possibly three: one in
svn_client.h, one in svn_ra_.h, and one in svn_fs.h. My original
intent was to implement just the svn_client.h function using calls to
RA->get_logs(), and then someday teach it to use a new svn_ra.h
function. But Shlomi has already started writing the svn_fs.h and
svn_ra.h functions, so now we need to "sync up" all 3 APIs. Is this
doable?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 8 22:43:08 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.