On Fri, Apr 23, 2010 at 06:37, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: > >> Specifically: in the particular case that *you* created the function >> for, the copyfrom-fetching would most likely *never* be invoked. >> node_get_url() should return a URL in almost every situation. > > The copyfrom stuff in libsvn_client/diff.c:convert_to_url dates to > pre-1.0 and was to fix issue 1229. In those days it appears that > copied items had copyfrom URLs but not URLs. > > Are there any circumstances today when a node will not have an URL but > will have a copyfrom URL? Everything seems to work if I remove the > copyfrom stuf from convert_to_url.
entry->url "does not exist"... today, we call a function to provide a URL. That means we can return a URL in every possible situation, for some semantic of "what does that URL represent?" In general(*), entry->url means "the repository location that the node came from, or where it will end up after a commit". And with that semantic, we can *almost* always provide an answer. The only situation that I can think of is where a switched subdir has been rm'd so we get back svn_wc__db_status_obstructed from the wc_db functions. If we use the parent's information, we can guess at a URL, but (due to the switch) it is wrong. Conceivably, we could *ensure* that enough information is left in the parent stub to properly compute the URL. We can always compute "where will this end up?" regardless of rm'd subdirs. Excluded/absent/etc nodes can be derived from the parent, as they are never switched. In single-db, the above-noted obstruction is no longer possible, which means we'll always have a URL according to the above definition. Cheers, -g (*) in general... in some cases, the url is "stale" and points elsewhere. see notes/api-errata/wc001.txt
