You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2010/04/23 10:37:52 UTC
Re: svn commit: r937010 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/diff.c libsvn_wc/copy.c libsvn_wc/node.c
Greg Stein <gs...@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.
--
Philip
Re: svn commit: r937010 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/diff.c libsvn_wc/copy.c libsvn_wc/node.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
>> I understand all that. My question is in the (few) cases where we
>> don't have an URL will we have a copyfrom URL. It seems unlikely to
>> me.
>
> I will state, "in any potential case where a URL is not available...
> NO, we will not have a copyfrom."
OK. The other places that retrieve the copyfrom URL in the client
library use it ahead of the URL -- the opposite to diff. I'll take it
out of diff.
--
Philip
Re: svn commit: r937010 - in /subversion/trunk/subversion:
include/private/svn_wc_private.h libsvn_client/diff.c libsvn_wc/copy.c
libsvn_wc/node.c
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 23, 2010 at 06:56, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>>> 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.
>
> I understand all that. My question is in the (few) cases where we
> don't have an URL will we have a copyfrom URL. It seems unlikely to
> me.
I will state, "in any potential case where a URL is not available...
NO, we will not have a copyfrom."
So: anything varying from that statement is a bug, so it can be taken
as axiomatic, and we work from there.
Cheers,
-g
Re: svn commit: r937010 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/diff.c libsvn_wc/copy.c libsvn_wc/node.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
>> 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.
I understand all that. My question is in the (few) cases where we
don't have an URL will we have a copyfrom URL. It seems unlikely to
me.
--
Philip
Re: svn commit: r937010 - in /subversion/trunk/subversion:
include/private/svn_wc_private.h libsvn_client/diff.c libsvn_wc/copy.c
libsvn_wc/node.c
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 23, 2010 at 06:37, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@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