Garret Wilson wrote on Mon, Jan 30, 2012 at 06:31:19 -0800:
> On 1/29/2012 11:26 PM, Daniel Shahaf wrote:
> >...
> >
> >- Publish your "properties migration" code for others to reuse.
>
> Done:
>
> https://...
Thanks.
> >[1] If you answer "In a specification" I'll ask how it would relate to
> >
On 01/29/2012 02:14 PM, Garret Wilson wrote:
> On 1/29/2012 10:55 AM, Branko Čibej wrote:
>> ... I can't help wondering why you didn't ask about valid property names
>> /before/ you created a bunch of invalid ones. Sounds like you made one too
>> many assumption.
>
> Wait, seriously? You're sayin
On Mon, Jan 30, 2012 at 06:31:19AM -0800, Garret Wilson wrote:
> Think about it in terms of XML: There is a specification for the XML
> API, the DOM: http://www.w3.org/TR/DOM-Level-3-Core/core.html .
> However, the API specification still depends on the definition of
> what XML itself is (e.g. what
On 1/29/2012 11:26 PM, Daniel Shahaf wrote:
...
- Publish your "properties migration" code for others to reuse.
Done:
https://svn.globalmentor.com/java/trunk/globalmentor-marmot/src/main/java/com/globalmentor/marmot/repository/svn/svnkit/SVNKitSubversionRepository.java
You'll need the relate
Philip Martin writes:
> Branko Čibej writes:
>
>> On 30.01.2012 11:14, Philip Martin wrote:
>>> - the backend FS layer allows any null terminated string as a property
>>>name
>>>
>>> - the frontend client layer restricts property names to a subset of
>>>ASCII
>>
>> And the HTTP layer h
On 30.01.2012 12:06, Philip Martin wrote:
> Philip Martin writes:
>
>> Branko Čibej writes:
>>
>>> On 30.01.2012 11:14, Philip Martin wrote:
- the backend FS layer allows any null terminated string as a property
name
- the frontend client layer restricts property names to
Philip Martin writes:
> Branko Čibej writes:
>
>> On 30.01.2012 11:14, Philip Martin wrote:
>>> - the backend FS layer allows any null terminated string as a property
>>>name
>>>
>>> - the frontend client layer restricts property names to a subset of
>>>ASCII
>>
>> And the HTTP layer h
Branko Čibej writes:
> On 30.01.2012 11:14, Philip Martin wrote:
>> - the backend FS layer allows any null terminated string as a property
>>name
>>
>> - the frontend client layer restricts property names to a subset of
>>ASCII
>
> And the HTTP layer has its own implicit restrictions.
On 30.01.2012 11:14, Philip Martin wrote:
> Daniel Shahaf writes:
>
>> - Send a patch to svn_repos__validate_props() (and make your case that
>> it should be applied)
> I think the current situation for property names is:
>
> - the backend FS layer allows any null terminated string as a propert
Daniel Shahaf writes:
> - Send a patch to svn_repos__validate_props() (and make your case that
> it should be applied)
I think the current situation for property names is:
- the backend FS layer allows any null terminated string as a property
name
- the frontend client layer restricts p
Some things you could still do include
- Make _concrete_ suggestions about what needs to be documented where.[1]
- Send a patch to svn_repos__validate_props() (and make your case that
it should be applied)
- Send a patch to the book
- Send a patch to the relevant API docs
- Publish your "pro
On 1/29/2012 10:55 AM, Branko Čibej wrote:
... I can't help wondering why you didn't ask about valid property
names /before/ you created a bunch of invalid ones. Sounds like you
made one too many assumption.
Wait, seriously? You're saying that, whenever there is an API call and I
pass someth
On 29.01.2012 18:25, Garret Wilson wrote:
> The story ends this way: I've spent days writing migration code which
> traverses the gigabytes of my various repositories and converts legacy
> property names (the ones I've been using for years over DAV+SVN, not
> knowing they were invalid in JavaHL) to
The story ends this way: I've spent days writing migration code which
traverses the gigabytes of my various repositories and converts legacy
property names (the ones I've been using for years over DAV+SVN, not
knowing they were invalid in JavaHL) to "valid" Subversion property
names (according
Garret Wilson wrote on Mon, Jan 23, 2012 at 21:03:30 -0800:
> On 1/23/2012 8:52 PM, Daniel Shahaf wrote:
> >In the past, people passed svn:log properties with embedded CRLFs
> >into that API --- which has been forbidden by some API doc or
> >another since 1.0.0, and is today caught and forbidden by
On 1/23/2012 8:52 PM, Daniel Shahaf wrote:
Personally I don't see any obvious reason for deciding that svn
property names can be, of all things, "any XML name" --- the fact our
wire protocol uses XML need not ripple into our public API; ..
I'm getting sleeping and I'm heading to bed, but I ju
On 1/23/2012 8:52 PM, Daniel Shahaf wrote:
In the past, people passed svn:log properties with embedded CRLFs into
that API --- which has been forbidden by some API doc or another since
1.0.0, and is today caught and forbidden by svn_repos__validate_prop().
Huh! Yeah, actually a long time ago I
Garret Wilson wrote on Mon, Jan 23, 2012 at 20:34:56 -0800:
> On 1/23/2012 8:23 PM, Daniel Shahaf wrote:
> >Sounds, then, like you're asking not for extending the set of valid
> >propnames but for enforcing the existing conventions?
>
> No, the part about "...not asking for extending..." not a cor
On 1/23/2012 8:23 PM, Daniel Shahaf wrote:
Sounds, then, like you're asking not for extending the set of valid
propnames but for enforcing the existing conventions?
No, the part about "...not asking for extending..." not a correct
characterization of what I'm requesting. I tried to be clear in
Sounds, then, like you're asking not for extending the set of valid
propnames but for enforcing the existing conventions?
Have a look at svn_repos__validate_prop() --- that's the function that
implements server-side validation of properties. Do you want to just
call svn_prop_name_is_valid() from
On 1/23/2012 11:50 AM, Philip Martin wrote:
... The situation is that the low level svn_fs.h API allows property
names to be any null-terminated C string. The intermediate svn_ra.h
API imposes restrictions because only XML names can be marshalled over
http:, I think svn: allows anything. The hi
Garret Wilson writes:
> On 1/23/2012 10:38 AM, Philip Martin wrote:
>> Garret Wilson writes:
>>
>>> On 1/23/2012 9:55 AM, Philip Martin wrote:
I thought you were proposing to write the code?
>>> I'm fine with that as well. Looks like I would have to add a few lines
>>> to decote UTF-8 (sure
On 1/23/2012 10:38 AM, Philip Martin wrote:
Garret Wilson writes:
On 1/23/2012 9:55 AM, Philip Martin wrote:
I thought you were proposing to write the code?
I'm fine with that as well. Looks like I would have to add a few lines
to decote UTF-8 (surely such code already exists in the Subversi
Garret Wilson writes:
> On 1/23/2012 9:55 AM, Philip Martin wrote:
>> I thought you were proposing to write the code?
>
> I'm fine with that as well. Looks like I would have to add a few lines
> to decote UTF-8 (surely such code already exists in the Subversion
> codebase somewhere) and change a
On 1/23/2012 9:55 AM, Philip Martin wrote:
So lots of high range Unicode points are allowed.
Yes.
How will we validate that?
The same way the code (as given to me by others) currently validates the
names---it iterates the characters provided, and if one of them doesn't
meet the definition
Garret Wilson writes:
> On 1/23/2012 9:23 AM, Philip Martin wrote:
>> What constitutes a valid XML name? I suppose it's things that don't
>> require XML escaping?
>
> An XML name is things like the name of an element, e.g. . You
> can't "escape" in an XML name, anyway. The specification of a vali
On 1/23/2012 9:23 AM, Philip Martin wrote:
What constitutes a valid XML name? I suppose it's things that don't
require XML escaping?
An XML name is things like the name of an element, e.g. . You
can't "escape" in an XML name, anyway. The specification of a valid XML
name is here:
http://www
Garret Wilson writes:
> 1. That the restriction in JavaHL svn_prop_name_is_valid() be lifted to
>allow a Subversion property to be any valid XML name, and
> 2. That there be a public specification that rigorously defines what
>makes a valid Subversion property name to prevent contradictor
On 1/23/2012 7:17 AM, C. Michael Pilato wrote:
On 01/23/2012 10:13 AM, Garret Wilson wrote:
By the lack of response am I to conclude that rigorous specification and
client interoperability are not considered high priorities on this list?
Conclude what you will. But a more accurate conclusion m
On 01/23/2012 10:13 AM, Garret Wilson wrote:
> By the lack of response am I to conclude that rigorous specification and
> client interoperability are not considered high priorities on this list?
Conclude what you will. But a more accurate conclusion might be "I've only
allowed a single 'business
By the lack of response am I to conclude that rigorous specification and
client interoperability are not considered high priorities on this list?
Garret
On 1/19/2012 2:20 PM, Garret Wilson wrote:
Summary: There seems to be no public specification (other than the
source code) on what makes a va
31 matches
Mail list logo
