On Fri, Apr 23, 2010 at 06:37, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_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
Received on 2010-04-23 12:48:54 CEST