On Sun, 24 Jul 2005, Julian Foad wrote:
> Frierich Munch wrote:
> > On 7/24/05 2:29 PM, "Julian Foad" <julianfoad@btopenworld.com> sneezed:
> >>Trying to parse property values into one of a number of different types seems
> >>to me inappropriate here. That cannot be done correctly without knowing what
> >>type of information each individual property contains.
> >
> > I think it's really beneficial. It's not command-line output, and I think
> > it should be as stateful as possible.
>
> If it was guaranteed to be correct I can see how it would be beneficial. What
> I don't understand is how a guess can be useful.
>
I strongly agree. This "datatype deduction" is really ugly because:
a) it's not always correct
b) it is an arbitrary list of types, whose usefulness I doubt. HOw often
would you associate real numbers as properties? Yes, it could happen, but
enumerated types would be more likely.
> >>If your goal is to have the known "svn:" properties parsed and presented
> >>specially
> >
> > That's not the goal. The goal is to represent information as stateful as
> > possible. I think special casing svn properties is more of a pain to
> > maintain.
>
> That's not a sufficient explanation of your goal. Special-casing svn
> properties would indeed have a maintenance burden, but at least the maintenance
> needed there would be at the same time and in the same code base as the changes
> that necessitated that maintenance.
>
Special-casing might be marginally useful in some cases (and make things
harder in other), but I don't think its worth the maintenance. You know,
we add a new svn: property. Then forget to update the DTD and get
complaints about invalid XML...
>
> Meanwhile, may I suggest that we concentrate on getting basic "proplist" XML
> output? I think that would be uncontroversial. If you are willing to change
> your patch to do that, it could be accepted soon and would get you a step
> closer to what you really want.
>
+1.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 00:19:24 2005