You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by cm...@apache.org on 2012/10/03 16:51:36 UTC
svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Author: cmpilato
Date: Wed Oct 3 14:51:36 2012
New Revision: 1393521
URL: http://svn.apache.org/viewvc?rev=1393521&view=rev
Log:
Use "svn:txn:" as the namespace for ephemeral txnprops, not
"svn:txn-". I was operating under this memory of Subversion having
trouble with colons in property names, but apparently that memory was
either obsolete or altogether bogus.
* subversion/include/svn_props.h
(SVN_PROP_TXN_PREFIX): Use "txn:" instead of "txn-".
* subversion/tests/cmdline/svnlook_tests.py
(test_txn_flag): Expect "svn:txn:..." instead of "svn:txn-..." now.
Modified:
subversion/trunk/subversion/include/svn_props.h
subversion/trunk/subversion/tests/cmdline/svnlook_tests.py
Modified: subversion/trunk/subversion/include/svn_props.h
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_props.h?rev=1393521&r1=1393520&r2=1393521&view=diff
==============================================================================
--- subversion/trunk/subversion/include/svn_props.h (original)
+++ subversion/trunk/subversion/include/svn_props.h Wed Oct 3 14:51:36 2012
@@ -551,7 +551,7 @@ svn_prop_name_is_valid(const char *prop_
*/
/** The prefix used for all (ephemeral) transaction properties. */
-#define SVN_PROP_TXN_PREFIX SVN_PROP_PREFIX "txn-"
+#define SVN_PROP_TXN_PREFIX SVN_PROP_PREFIX "txn:"
/** Identifies the client version compability level. For clients
* compiled against Subversion libraries, this is @c SVN_VER_NUMBER.
Modified: subversion/trunk/subversion/tests/cmdline/svnlook_tests.py
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/svnlook_tests.py?rev=1393521&r1=1393520&r2=1393521&view=diff
==============================================================================
--- subversion/trunk/subversion/tests/cmdline/svnlook_tests.py (original)
+++ subversion/trunk/subversion/tests/cmdline/svnlook_tests.py Wed Oct 3 14:51:36 2012
@@ -701,11 +701,11 @@ fp.close()"""
' svn:check-locks\n', # internal prop, not really expected
' bogus_rev_prop\n',
' svn:date\n',
- ' svn:txn-client-compat-version\n',
+ ' svn:txn:client-compat-version\n',
]
# ra_dav and ra_svn add the user-agent ephemeral property
if svntest.main.is_ra_type_dav() or svntest.main.is_ra_type_svn():
- expected_data.append(' svn:txn-user-agent\n')
+ expected_data.append(' svn:txn:user-agent\n')
verify_logfile(logfilepath, svntest.verify.UnorderedOutput(expected_data))
def property_delete(sbox):
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Роман Донченко <dp...@corrigendum.ru>.
C. Michael Pilato <cm...@collab.net> писал в своём письме Thu, 04 Oct
2012 16:54:56 +0400:
> But a picky XML parser would see "svn:txn:foo" or "svn:config:foo" and
> want
> to know about the XML namespaces "svn:txn" and "svn:config", which we
> don't
> bother to describe. There's a fairly straightforward workaround, I
> think,
> where we simply generate xmlns definitions on the fly for all namespaces
> we
> need for that particular request/response. I think this is essentially
> what
> was being described here:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=480154
If the XML parser supports namespaces, then "svn:txn:foo" is not a
permissible name, because namespace prefixes can't contain colons (and
neither can local parts).
Of course, if the parser doesn't support namespaces, then it's a perfectly
fine name.
Roman.
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Oct 9, 2012 at 12:39 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 10/05/2012 05:48 PM, Ben Reser wrote:
>> On Fri, Oct 5, 2012 at 7:12 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> That's right. Expat just doesn't care. Some other XML parser might. But
>>> then, I would expect that same parser would croak on any property name with
>>> a colon in it (besides "svn:", which we handle specially already). So all
>>> of TortoiseSVN's properties, cvs2svn's properties, etc. -- all that stops
>>> working.
>>
>> [snip]
>>
>>> I don't think so. I think that would be just a lovely instance of the
>>> perfect being the enemy of the good [enough]. If it becomes a real-world
>>> problem, our recourse is rather straightforward -- we continue our move away
>>> from the DAV standard and implement our own custom POST/REPORT handling.
>>
>> My memory is fuzzy on this and it's been 5-6 years but ISTR that the
>> problem was with people using auto versioning since the XML wouldn't
>> be valid.
>>
>> -1: On just doing this and hoping for the best. If it really is auto
>> versioning that breaks due to this, it is a supported feature of our
>> code set and not one that I suspect any of us test very often. If we
>> test auto versioning with the most commonly used configs and we have
>> no issues then I'd be +0.
>
> Just some thoughts/comments in no particular order:
>
> - IIRC, autoversioning clients are broken in this respect anyway, and simply
> can't be fixed because Subversion's property storage namespace is flat and
> WebDAV's is all ns&name's. We could store autoversioning client-generated
> properties with URI-ish names (ns + "/" + uri_encode(name)) or something,
> but we've historically just silently dumped the namespaces for properties
> from those clients. Autoversioning clients also won't care about my
> svn:txn: properties because those only exist on transactions and revisions,
> which are resource types that autoversioning clients don't care about.
> (They focus on the directory trees.)
>
> - Last week I went ahead and started looking into revamping our propget/set
> DAV protocol so that this problem no longer exists for HTTPv2 clients. This
> is fairly trivial work, but also seems less useful overall. If a client is
> speaking HTTPv2, it's already doing Subversion-specific stuff and not strick
> DAV compliance, so it surely is capable of gracefully dealing with our
> current broken handling of colon-bearing properties.
>
> - Yesterday I started coding a more generic approach to colon-bearing
> properties. libsvn_ra_serf and mod_dav_svn now relay xmlns mappings of a
> dynamically generated prefix to a URI which is a child of a fixed
> "extensible xmlns URI". So a property such as "svn:config:foo" gets
> transmitted as "<svn0:foo>" (or "<svn1:foo>", or "<svn2:foo>" ...) with a
> prior declaration that the "svn0" prefix maps to the namespace
> "http://subversion.apache.org/xmlns/ext/svn:config". So long as both ends
> of the wire know what's so special about that namespace URI (as they
> currently do with the "svn", "dav", and "custom" namespace URIs we employ),
> stuff seems to generally work. I'll toss this work onto a branch a bit
> later, because I've not done any extensive testing and I'm not convinced
> that doing so is the best use of my time.
>
> - I will revert my use of svn:txn:* for ephemeral txnprops, and will
> formally recommend to Paul that he switch to svn:config-* for his
> autoprops-sdc branch.
Done r1396184.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
> At a minimum, those changes will not effect the
> existing WebDAV property support levels at all, and that's probably for the
> best at this phase of the release cycle.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/05/2012 05:48 PM, Ben Reser wrote:
> On Fri, Oct 5, 2012 at 7:12 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> That's right. Expat just doesn't care. Some other XML parser might. But
>> then, I would expect that same parser would croak on any property name with
>> a colon in it (besides "svn:", which we handle specially already). So all
>> of TortoiseSVN's properties, cvs2svn's properties, etc. -- all that stops
>> working.
>
> [snip]
>
>> I don't think so. I think that would be just a lovely instance of the
>> perfect being the enemy of the good [enough]. If it becomes a real-world
>> problem, our recourse is rather straightforward -- we continue our move away
>> from the DAV standard and implement our own custom POST/REPORT handling.
>
> My memory is fuzzy on this and it's been 5-6 years but ISTR that the
> problem was with people using auto versioning since the XML wouldn't
> be valid.
>
> -1: On just doing this and hoping for the best. If it really is auto
> versioning that breaks due to this, it is a supported feature of our
> code set and not one that I suspect any of us test very often. If we
> test auto versioning with the most commonly used configs and we have
> no issues then I'd be +0.
Just some thoughts/comments in no particular order:
- IIRC, autoversioning clients are broken in this respect anyway, and simply
can't be fixed because Subversion's property storage namespace is flat and
WebDAV's is all ns&name's. We could store autoversioning client-generated
properties with URI-ish names (ns + "/" + uri_encode(name)) or something,
but we've historically just silently dumped the namespaces for properties
from those clients. Autoversioning clients also won't care about my
svn:txn: properties because those only exist on transactions and revisions,
which are resource types that autoversioning clients don't care about.
(They focus on the directory trees.)
- Last week I went ahead and started looking into revamping our propget/set
DAV protocol so that this problem no longer exists for HTTPv2 clients. This
is fairly trivial work, but also seems less useful overall. If a client is
speaking HTTPv2, it's already doing Subversion-specific stuff and not strick
DAV compliance, so it surely is capable of gracefully dealing with our
current broken handling of colon-bearing properties.
- Yesterday I started coding a more generic approach to colon-bearing
properties. libsvn_ra_serf and mod_dav_svn now relay xmlns mappings of a
dynamically generated prefix to a URI which is a child of a fixed
"extensible xmlns URI". So a property such as "svn:config:foo" gets
transmitted as "<svn0:foo>" (or "<svn1:foo>", or "<svn2:foo>" ...) with a
prior declaration that the "svn0" prefix maps to the namespace
"http://subversion.apache.org/xmlns/ext/svn:config". So long as both ends
of the wire know what's so special about that namespace URI (as they
currently do with the "svn", "dav", and "custom" namespace URIs we employ),
stuff seems to generally work. I'll toss this work onto a branch a bit
later, because I've not done any extensive testing and I'm not convinced
that doing so is the best use of my time.
- I will revert my use of svn:txn:* for ephemeral txnprops, and will
formally recommend to Paul that he switch to svn:config-* for his
autoprops-sdc branch. At a minimum, those changes will not effect the
existing WebDAV property support levels at all, and that's probably for the
best at this phase of the release cycle.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Ben Reser <be...@reser.org>.
On Fri, Oct 5, 2012 at 7:12 AM, C. Michael Pilato <cm...@collab.net> wrote:
> That's right. Expat just doesn't care. Some other XML parser might. But
> then, I would expect that same parser would croak on any property name with
> a colon in it (besides "svn:", which we handle specially already). So all
> of TortoiseSVN's properties, cvs2svn's properties, etc. -- all that stops
> working.
[snip]
> I don't think so. I think that would be just a lovely instance of the
> perfect being the enemy of the good [enough]. If it becomes a real-world
> problem, our recourse is rather straightforward -- we continue our move away
> from the DAV standard and implement our own custom POST/REPORT handling.
My memory is fuzzy on this and it's been 5-6 years but ISTR that the
problem was with people using auto versioning since the XML wouldn't
be valid.
-1: On just doing this and hoping for the best. If it really is auto
versioning that breaks due to this, it is a supported feature of our
code set and not one that I suspect any of us test very often. If we
test auto versioning with the most commonly used configs and we have
no issues then I'd be +0.
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/05/2012 09:30 AM, Mark Phippard wrote:
> On Fri, Oct 5, 2012 at 9:26 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
>> My understanding was that the namespaces were kinda treated like opaque
>> strings, so "nesting" isn't really even interesting from an XML parser
>> standpoint so much as mere "uniqueness" is.
>>
>> Top answer here (plus the "nit" comment thereupon) seems to confirm as much:
>> http://stackoverflow.com/questions/588919/what-is-the-practice-for-nesting-xml-namespaces
>
> I notice you have not backed out your change, so what is the net
> result of all of this?
>
> I am assuming you committed your patch because you did not see a
> problem. Is it just that expat does not validate the namespace but
> this could be a problem with some other XML parser?
That's right. Expat just doesn't care. Some other XML parser might. But
then, I would expect that same parser would croak on any property name with
a colon in it (besides "svn:", which we handle specially already). So all
of TortoiseSVN's properties, cvs2svn's properties, etc. -- all that stops
working.
> Given that, what does it mean for your change, and possibly Paul's
> branch? Should you go back to using the dash?
I don't think so. I think that would be just a lovely instance of the
perfect being the enemy of the good [enough]. If it becomes a real-world
problem, our recourse is rather straightforward -- we continue our move away
from the DAV standard and implement our own custom POST/REPORT handling.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Oct 5, 2012 at 9:26 AM, C. Michael Pilato <cm...@collab.net> wrote:
> My understanding was that the namespaces were kinda treated like opaque
> strings, so "nesting" isn't really even interesting from an XML parser
> standpoint so much as mere "uniqueness" is.
>
> Top answer here (plus the "nit" comment thereupon) seems to confirm as much:
> http://stackoverflow.com/questions/588919/what-is-the-practice-for-nesting-xml-namespaces
I notice you have not backed out your change, so what is the net
result of all of this?
I am assuming you committed your patch because you did not see a
problem. Is it just that expat does not validate the namespace but
this could be a problem with some other XML parser?
Given that, what does it mean for your change, and possibly Paul's
branch? Should you go back to using the dash?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/04/2012 02:21 PM, Branko Čibej wrote:
> On 04.10.2012 17:19, C. Michael Pilato wrote:
>> On 10/04/2012 11:01 AM, Ben Reser wrote:
>>> I recall trying to do that and it wouldn't work. I do believe
>>> namespaces is how we resolved it for svn:foo style properties. If
>>> we're going to be doing svn:foo:bar style properties then we can
>>> probably resolve it for svn:foo properties that way by adding a
>>> namespace for them. As I recall there was no clean way to tell the
>>> client what the namespace meant. Specifically how do you get from
>>> randomnamespacename -> cvs2svn:cvs-rev. The places where we could put
>>> that information had other character restrictions that made it
>>> difficult.
>> You may be right. I've not spelunked in the DAV specs for quite some years
>> now. I can see that PROPFIND responses carry the sort of information I was
>> talking about:
>>
>> <D:response
>> xmlns:S="http://subversion.tigris.org/xmlns/svn/"
>> xmlns:C="http://subversion.tigris.org/xmlns/custom/"
>> xmlns:V="http://subversion.tigris.org/xmlns/dav/"
>> xmlns:lp1="DAV:"
>> xmlns:lp3="http://subversion.tigris.org/xmlns/dav/"
>> xmlns:lp2="http://apache.org/dav/props/">
>>
>> But I haven't really looked to see if PROPFIND *requests* can do the same,
>> or what the state of PROPPATCH requests/responses are in this respect.
>
> Does XML even define nested namespaces?
My understanding was that the namespaces were kinda treated like opaque
strings, so "nesting" isn't really even interesting from an XML parser
standpoint so much as mere "uniqueness" is.
Top answer here (plus the "nit" comment thereupon) seems to confirm as much:
http://stackoverflow.com/questions/588919/what-is-the-practice-for-nesting-xml-namespaces
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by Branko Čibej <br...@wandisco.com>.
On 04.10.2012 17:19, C. Michael Pilato wrote:
> On 10/04/2012 11:01 AM, Ben Reser wrote:
>> I recall trying to do that and it wouldn't work. I do believe
>> namespaces is how we resolved it for svn:foo style properties. If
>> we're going to be doing svn:foo:bar style properties then we can
>> probably resolve it for svn:foo properties that way by adding a
>> namespace for them. As I recall there was no clean way to tell the
>> client what the namespace meant. Specifically how do you get from
>> randomnamespacename -> cvs2svn:cvs-rev. The places where we could put
>> that information had other character restrictions that made it
>> difficult.
> You may be right. I've not spelunked in the DAV specs for quite some years
> now. I can see that PROPFIND responses carry the sort of information I was
> talking about:
>
> <D:response
> xmlns:S="http://subversion.tigris.org/xmlns/svn/"
> xmlns:C="http://subversion.tigris.org/xmlns/custom/"
> xmlns:V="http://subversion.tigris.org/xmlns/dav/"
> xmlns:lp1="DAV:"
> xmlns:lp3="http://subversion.tigris.org/xmlns/dav/"
> xmlns:lp2="http://apache.org/dav/props/">
>
> But I haven't really looked to see if PROPFIND *requests* can do the same,
> or what the state of PROPPATCH requests/responses are in this respect.
Does XML even define nested namespaces?
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/04/2012 11:01 AM, Ben Reser wrote:
> I recall trying to do that and it wouldn't work. I do believe
> namespaces is how we resolved it for svn:foo style properties. If
> we're going to be doing svn:foo:bar style properties then we can
> probably resolve it for svn:foo properties that way by adding a
> namespace for them. As I recall there was no clean way to tell the
> client what the namespace meant. Specifically how do you get from
> randomnamespacename -> cvs2svn:cvs-rev. The places where we could put
> that information had other character restrictions that made it
> difficult.
You may be right. I've not spelunked in the DAV specs for quite some years
now. I can see that PROPFIND responses carry the sort of information I was
talking about:
<D:response
xmlns:S="http://subversion.tigris.org/xmlns/svn/"
xmlns:C="http://subversion.tigris.org/xmlns/custom/"
xmlns:V="http://subversion.tigris.org/xmlns/dav/"
xmlns:lp1="DAV:"
xmlns:lp3="http://subversion.tigris.org/xmlns/dav/"
xmlns:lp2="http://apache.org/dav/props/">
But I haven't really looked to see if PROPFIND *requests* can do the same,
or what the state of PROPPATCH requests/responses are in this respect.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Ben Reser <be...@reser.org>.
On Thu, Oct 4, 2012 at 5:54 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 10/03/2012 03:39 PM, Mark Phippard wrote:
>> On Wed, Oct 3, 2012 at 10:51 AM, <cm...@apache.org> wrote:
>>> Author: cmpilato
>>> Date: Wed Oct 3 14:51:36 2012
>>> New Revision: 1393521
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1393521&view=rev
>>> Log:
>>> Use "svn:txn:" as the namespace for ephemeral txnprops, not
>>> "svn:txn-". I was operating under this memory of Subversion having
>>> trouble with colons in property names, but apparently that memory was
>>> either obsolete or altogether bogus.
>>
>> I was looking at the open Serf issues for 1.8 and saw this:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1971
>>
>> Is that what you were remembering?
>>
>
> Yes, I believe it was. I remembered that PROPFINDs and PROPPATCHs use the
> property name as an XML tag, so we already require that property names be
> essentially well-formed XML "Names". The book mentions this, too:
>
> {{{
> There are some restrictions on the names you can use for properties. A
> property name must start with a letter, a colon (:), or an underscore (_);
> after that, you can also use digits, hyphens (-), and periods (.)
> }}}
>
> But a picky XML parser would see "svn:txn:foo" or "svn:config:foo" and want
> to know about the XML namespaces "svn:txn" and "svn:config", which we don't
> bother to describe. There's a fairly straightforward workaround, I think,
> where we simply generate xmlns definitions on the fly for all namespaces we
> need for that particular request/response. I think this is essentially what
> was being described here:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=480154
I recall trying to do that and it wouldn't work. I do believe
namespaces is how we resolved it for svn:foo style properties. If
we're going to be doing svn:foo:bar style properties then we can
probably resolve it for svn:foo properties that way by adding a
namespace for them. As I recall there was no clean way to tell the
client what the namespace meant. Specifically how do you get from
randomnamespacename -> cvs2svn:cvs-rev. The places where we could put
that information had other character restrictions that made it
difficult.
Re: svn commit: r1393521 - in /subversion/trunk/subversion: include/svn_props.h
tests/cmdline/svnlook_tests.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/03/2012 03:39 PM, Mark Phippard wrote:
> On Wed, Oct 3, 2012 at 10:51 AM, <cm...@apache.org> wrote:
>> Author: cmpilato
>> Date: Wed Oct 3 14:51:36 2012
>> New Revision: 1393521
>>
>> URL: http://svn.apache.org/viewvc?rev=1393521&view=rev
>> Log:
>> Use "svn:txn:" as the namespace for ephemeral txnprops, not
>> "svn:txn-". I was operating under this memory of Subversion having
>> trouble with colons in property names, but apparently that memory was
>> either obsolete or altogether bogus.
>
> I was looking at the open Serf issues for 1.8 and saw this:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1971
>
> Is that what you were remembering?
>
Yes, I believe it was. I remembered that PROPFINDs and PROPPATCHs use the
property name as an XML tag, so we already require that property names be
essentially well-formed XML "Names". The book mentions this, too:
{{{
There are some restrictions on the names you can use for properties. A
property name must start with a letter, a colon (:), or an underscore (_);
after that, you can also use digits, hyphens (-), and periods (.)
}}}
But a picky XML parser would see "svn:txn:foo" or "svn:config:foo" and want
to know about the XML namespaces "svn:txn" and "svn:config", which we don't
bother to describe. There's a fairly straightforward workaround, I think,
where we simply generate xmlns definitions on the fly for all namespaces we
need for that particular request/response. I think this is essentially what
was being described here:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=480154
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1393521 - in /subversion/trunk/subversion:
include/svn_props.h tests/cmdline/svnlook_tests.py
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 3, 2012 at 10:51 AM, <cm...@apache.org> wrote:
> Author: cmpilato
> Date: Wed Oct 3 14:51:36 2012
> New Revision: 1393521
>
> URL: http://svn.apache.org/viewvc?rev=1393521&view=rev
> Log:
> Use "svn:txn:" as the namespace for ephemeral txnprops, not
> "svn:txn-". I was operating under this memory of Subversion having
> trouble with colons in property names, but apparently that memory was
> either obsolete or altogether bogus.
I was looking at the open Serf issues for 1.8 and saw this:
http://subversion.tigris.org/issues/show_bug.cgi?id=1971
Is that what you were remembering?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/