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

Re: File externals and wc style questions

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 09 Jun 2008 13:31:28 -0400

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.


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

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.