Blair Zajac <blair_at_orcaware.com> writes:
>>> Oh yes, and why do we have svn_wc__atts_to_entry()? This looks like
>>> it's more XML entries files related?
>>
>> Sure, I assume so. We still have to be able to read those, though,
>> right?
>
> Well, do we? All the newer formats are non-XML, so we would never
> expect to find those newer entry fields in there.
Oh. Heh. Uh, good point, yeah.
>>> +{
>>> + svn_opt_revision_t r;
>>> +
>>> + if (! rev_str)
>>> + r.kind = svn_opt_revision_head;
>>> + else
>>> + {
>>> + if (strcmp(rev_str, SVN_WC__ENTRY_VALUE_HEAD) == 0)
>>> + {
>>> + }
>>
>> ?? :-)
>
> Well, svn_opt_revision_head is the default and if the string is HEAD,
> then don't do anything.
I think it might be better to represent that with a comment. An empty
block just looks like someone got interrupted by the doorbell while
coding or something.
> I was thinking we need to do that. The way this will be implemented
> is that under the hood, file externals will just be switched files.
>
> Say you don't bump the wc format and you have a 1.5 and 1.6 client and
> the 1.6 client makes a file external in a wc. The 1.5 client will see
> it as a simple switched file and possible update it and do other
> operations on it that shouldn't be possible on a file external. So I
> think its safer to bump the wc format.
Mmmmrph. I understand, but you might want to raise this issue in a
separate thread. Working copy bumps can be very painful; we should at
least make sure the dev team agrees that it's worth it here.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-09 19:31:49 CEST