You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2006/03/17 19:32:52 UTC
Re: svn commit: r18932 - trunk/subversion/include
malcolm@tigris.org writes:
> Author: malcolm
> Date: Fri Mar 17 10:12:56 2006
> New Revision: 18932
>
> Modified: trunk/subversion/include/svn_xml.h
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/include/svn_xml.h?pathrev=18932&r1=18931&r2=18932
> ==============================================================================
> --- trunk/subversion/include/svn_xml.h (original)
> +++ trunk/subversion/include/svn_xml.h Fri Mar 17 10:12:56 2006
> @@ -67,8 +67,10 @@
> svn_boolean_t svn_xml_is_xml_safe(const char *data,
> apr_size_t len);
>
> -/** Check whether the UTF8 NAME is a the ASCII subset of an XML "Name".
> - * XML "Name" is defined at http://www.w3.org/TR/REC-xml#sec-common-syn
> +/** Determine whether the UTF-8 string @a name is both a valid XML "Name",
> + * and one that uses only ASCII characters.
> + *
> + * The XML Name production is defined at http://www.w3.org/TR/REC-xml/#dt-name
> *
> * @since New in 1.4.
> */
>
Hmmm, would it be better to document the ASCII part as a @todo or @bug?
That would allow us to extend this function to cover the whole Name
production when someone gets around to it.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why tags as branches?
Posted by Greg Hudson <gh...@MIT.EDU>.
1. When you reply to a mail message and change the subject, it still
gets threaded in with the old conversation in many archives and mail
clients. Open a new message and copy in the address intead.
2. Your message body showed up in my mail client as an attachment which
didn't display by default. Not sure if my mail client (Evolution) is
unusual in how it displays such messages, but your message is certainly
unusual among the ones I receive.
3. This issue comes up a lot. See
http://svn.haxx.se/dev/archive-2006-02/1423.shtml for a thread about it
from last month. (Note that the thread is somewhat broken up in that
archive.)
If you have more to say on this subject after reading the referenced
material, please say it in a fresh thread. This one is likely to be
lost because of (1).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Why tags as branches?
Posted by John Calcote <jc...@novell.com>.
Subversion designers,
I've been reading a LOT of material on subversion lately, and I've got to ask:
Why did you implement tags as branches?
Tags are conceptually just bookmarks in a version control system. It would have been trivial to implement tags as a hash table of revision number aliases, since that's what they really are. Then there would be no chance of inadvertently converting a branch to a tag.
The svn client might have had a new call:
svn tag https://some.domain/svn/project1[@rnn] TAG_NAME
Or even better:
svn propset https://some.domain/svn/project1 svn:tags TAG_NAME:rnn
To use a tag, you might then just do this:
svn update -rTAG_NAME
This syntax is similar to saying svn update -rPREV.
Aren't PREV, BASE, COMMITTED, and HEAD just pseudo-tags, anyway?
John
John Calcote
Sr. Software Engineer
jcalcote@novell.com
801.861.7517
Re: svn commit: r18932 - trunk/subversion/include
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Malcolm Rowe writes:
> On Fri, Mar 17, 2006 at 08:32:52PM +0100, Peter N. Lundblad wrote:
> > Hmmm, would it be better to document the ASCII part as a @todo or @bug?
> > That would allow us to extend this function to cover the whole Name
> > production when someone gets around to it.
> >
>
> I don't know whether the ASCII part is intended or not
It is not intentinal, at least not in the long run. See issue #2139.
> - and in any case,
> it would seem a little unreasonable to change the function so drastically.
> Maybe.
I think it is fine to allow this function to be extended to allow all
valid XML names in the future.
> The checkin that I did was just a clarification to the docstring zhakov
I know. It just caught my attention:-) That's what you get when you
do some cleanups in an area:-) (I can fix this myself if no one
objects, of course).
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Julian Foad <ju...@btopenworld.com>.
Malcolm Rowe wrote:
> On Fri, Mar 17, 2006 at 11:46:21PM +0000, Julian Foad wrote:
>
>>Well, it depends on how we advertise (document) it. The way Malcolm has
>>described it, its purpose is clearly to allow only the ASCII sub-set, and
>>callers will have a right to rely on that.
>>
>>The other way of doing this, "document the current limitation", is fine as
>>long as it is very clear, such as:
>>
>>+/** Determine whether the UTF-8 string @a name is a valid XML "Name".
>>+ * Return TRUE if it definitely is, and FALSE if not or if this function
>>+ * is unsure. (Early implementations of this function recognise only
>>+ * the ASCII subset of XML "Names".)
>
> Yes, that sounds like a better idea. Let me know if you'd like me to
> update the docstring again. (I'm not really following the discussion
> about exports, so I'm not sure if you're also suggesting we might want
> to drop the function altogether).
I am suggesting and hoping that we'll drop it altogether, so there's not much
point in changing it until we get that sorted out. I'll keep an eye on it and
make sure we do something about it before branching for v1.4.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, Mar 17, 2006 at 11:46:21PM +0000, Julian Foad wrote:
> Well, it depends on how we advertise (document) it. The way Malcolm has
> described it, its purpose is clearly to allow only the ASCII sub-set, and
> callers will have a right to rely on that.
>
> The other way of doing this, "document the current limitation", is fine as
> long as it is very clear, such as:
>
> +/** Determine whether the UTF-8 string @a name is a valid XML "Name".
> + * Return TRUE if it definitely is, and FALSE if not or if this function
> + * is unsure. (Early implementations of this function recognise only
> + * the ASCII subset of XML "Names".)
>
Yes, that sounds like a better idea. Let me know if you'd like me to
update the docstring again. (I'm not really following the discussion
about exports, so I'm not sure if you're also suggesting we might want
to drop the function altogether).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Julian Foad <ju...@btopenworld.com>.
+/** Determine whether the UTF-8 string @a name is both a valid XML "Name",
+ * and one that uses only ASCII characters.
+ *
+ * The XML Name production is defined at http://www.w3.org/TR/REC-xml/#dt-name
*
* @since New in 1.4.
*/
Peter N. Lundblad wrote:
> Julian Foad writes:
> > Malcolm Rowe wrote:
> > 1. Re. semantics: For this to be a public API, your new doc string is a good
> > description of the implementation, and these are acceptable semantics for a
> > public API, but its name ought to reflect the ASCII aspect of its semantics.
> >
> > At some later stage we're bound to want an "is_xml_name" with full UTF-8
> > semantics, and I don't think it's OK to later change the meaning that much.
>
> Yes, I think it is OK if we document the current limitation of this
> function. I object to renaming this to something including _ascii_
> (or whatever) because it will be cruft that no one will want to use
> when (if) the function is properly and completely implemented. Note
> that this function is new in 1.4, so are free to change its semantics.
Well, it depends on how we advertise (document) it. The way Malcolm has
described it, its purpose is clearly to allow only the ASCII sub-set, and
callers will have a right to rely on that.
The other way of doing this, "document the current limitation", is fine as long
as it is very clear, such as:
+/** Determine whether the UTF-8 string @a name is a valid XML "Name".
+ * Return TRUE if it definitely is, and FALSE if not or if this function
+ * is unsure. (Early implementations of this function recognise only
+ * the ASCII subset of XML "Names".)
> > 2. Re. r18202: that commit purports to avoid sharing variables
> > (svn_ctype_table) between libraries:
> >
> > That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
> > at the time, but did nothing to prevent such use. The email discussion said
> > that public access to svn_ctype_table[] was to be deprecated, which would
> > require the svn_ctype_* macros to be converted to functions, but that has not
> > been done. Now there are other uses outside libsvn_subr, so presumably the
> > Win32 DLLs again don't build/work properly - is that the case?
>
> I guess so.
>
> > I think that commit wasn't a proper way to solve the problem. If we solve the
> > variable-sharing problem properly, then that commit r18202 can be reverted, and
>
> Agreed. Someone with enough motivation for Windows DLLs?
Actually, unless I'm much mistaken, r18202 can be reverted before solving the
variable-sharing problem properly, because it isn't solving it at all at the
moment. Ivan, do you agree? If so, will you do that, please?
> > the problem of how to name and describe the XML-name function goes away. That
> > would be good because we've no reason to want such a function in our public
> > API, as far as I know.
> >
> Other clients could find it useful to be able to validate a property
> name, but let's not add a public API for that weak reason:-)
Right.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Julian Foad writes:
> Malcolm Rowe wrote:
> 1. Re. semantics: For this to be a public API, your new doc string is a good
> description of the implementation, and these are acceptable semantics for a
> public API, but its name ought to reflect the ASCII aspect of its semantics.
>
> At some later stage we're bound to want an "is_xml_name" with full UTF-8
> semantics, and I don't think it's OK to later change the meaning that much.
Yes, I think it is OK if we document the current limitation of this
function. I object to renaming this to something including _ascii_
(or whatever) because it will be cruft that no one will want to use
when (if) the function is properly and completely implemented. Note
that this function is new in 1.4, so are free to change its semantics.
>
> 2. Re. r18202: that commit purports to avoid sharing variables
> (svn_ctype_table) between libraries:
>
> That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
> at the time, but did nothing to prevent such use. The email discussion said
> that public access to svn_ctype_table[] was to be deprecated, which would
> require the svn_ctype_* macros to be converted to functions, but that has not
> been done. Now there are other uses outside libsvn_subr, so presumably the
> Win32 DLLs again don't build/work properly - is that the case?
I guess so.
> I think that commit wasn't a proper way to solve the problem. If we solve the
> variable-sharing problem properly, then that commit r18202 can be reverted, and
Agreed. Someone with enough motivation for Windows DLLs?
> the problem of how to name and describe the XML-name function goes away. That
> would be good because we've no reason to want such a function in our public
> API, as far as I know.
>
Other clients could find it useful to be able to validate a property
name, but let's not add a public API for that weak reason:-)
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Ivan Zhakov writes:
> At the moment when I commited this change, it was only one usage of
> svn_ctype out of libsvn_subr module. I was going to deprecated
> svn_ctype_table, but this requires function call for each access,
> which could decrease performance.
The problem is that svn_ctype_* are meant to be used, and we can't
just move all uses inside libsvn_subr.
> Anyway I didn't see reasons why we cannot leave
> svn_xml_is_ascii_xml_name in our public API? We already have function
> svn_xml_is_xml_safe().
It is an ugly incomplete API that has no place in our public APIs.
> I don't press for keep it, so revert my commit if you consider.
>
Let's get that done before 1.4 (or reimplement it to support the full
XML character repertoire).
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Julian Foad <ju...@btopenworld.com>.
Ivan Zhakov wrote:
> Anyway I didn't see reasons why we cannot leave
> svn_xml_is_ascii_xml_name in our public API? We already have function
> svn_xml_is_xml_safe().
The reason we should not rename it to svn_xml_is_ascii_xml_name() and leave it
in our public API is because we have no reason to believe that any caller would
want to use such a function. The only caller we currently have,
is_valid_prop_name(), does not "want" to use that function. It only uses it
because nothing better is available yet.
> I don't press for keep it, so revert my commit if you consider.
Thanks. I've reverted it in r18995.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Ivan Zhakov <ch...@gmail.com>.
On 3/18/06, Julian Foad <ju...@btopenworld.com> wrote:
> Malcolm Rowe wrote:
> > On Fri, Mar 17, 2006 at 08:32:52PM +0100, Peter N. Lundblad wrote:
>
> Re. svn_xml_is_xml_name():
>
> >>Hmmm, would it be better to document the ASCII part as a @todo or @bug?
> >>That would allow us to extend this function to cover the whole Name
> >>production when someone gets around to it.
> >
> > I don't know whether the ASCII part is intended or not - and in any case,
> > it would seem a little unreasonable to change the function so drastically.
> > Maybe.
> >
> > The checkin that I did was just a clarification to the docstring zhakov
> > introduced in r18202. Ah, I see that Julian originally introduced this
> > function in r7528 - maybe he has an opinion as to what the contract
> > should actually be, now that the function is public?
>
> 1. Re. semantics: For this to be a public API, your new doc string is a good
> description of the implementation, and these are acceptable semantics for a
> public API, but its name ought to reflect the ASCII aspect of its semantics.
>
> At some later stage we're bound to want an "is_xml_name" with full UTF-8
> semantics, and I don't think it's OK to later change the meaning that much.
>
> Therefore let's name it something like "svn_xml_is_ascii_xml_name".
>
I completly agree with proposed function name.
>
> 2. Re. r18202: that commit purports to avoid sharing variables
> (svn_ctype_table) between libraries:
>
> > ------------------------------------------------------------------------
> > r18202 | zhakov | 2006-01-24 14:12:31 +0000 (Tue, 24 Jan 2006) | 13 lines
> > Changed paths:
> > M /trunk/subversion/include/svn_xml.h
> > M /trunk/subversion/libsvn_client/prop_commands.c
> > M /trunk/subversion/libsvn_subr/xml.c
> >
> > Factor out svn_xml_is_xml_name_valid() to eliminate usage of
> > svn_ctype_table variable outside of libsvn_subr library. This needed because
> > exporting variables from Windows DLLs requires __declspec(dllexport).
> > See disscussion here: http://svn.haxx.se/dev/archive-2005-12/0178.shtml
> >
> > * subversion/include/svn_xml.h
> > * subversion/libsvn_subr/xml.c
> > (svn_xml_is_xml_name_valid): New function, factored out from
> > is_valid_prop_name()
> >
> > * subversion/libsvn_client/prop_commands.c:
> > (is_valid_prop_name): Use new function svn_xml_is_xml_name_valid()
> >
> > ------------------------------------------------------------------------
> > Index: subversion/include/svn_xml.h
> > ===================================================================
> [...]
> > +/** Check whether the UTF8 NAME is a the ASCII subset of an XML "Name".
> > + * XML "Name" is defined at http://www.w3.org/TR/REC-xml#sec-common-syn
> > + *
> > + * @since New in 1.4.
> > + */
> > +svn_boolean_t svn_xml_is_xml_name_valid (const char *name);
>
> That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
> at the time, but did nothing to prevent such use. The email discussion said
> that public access to svn_ctype_table[] was to be deprecated, which would
> require the svn_ctype_* macros to be converted to functions, but that has not
> been done. Now there are other uses outside libsvn_subr, so presumably the
> Win32 DLLs again don't build/work properly - is that the case?
>
> I think that commit wasn't a proper way to solve the problem. If we solve the
> variable-sharing problem properly, then that commit r18202 can be reverted, and
> the problem of how to name and describe the XML-name function goes away. That
> would be good because we've no reason to want such a function in our public
> API, as far as I know.
>
At the moment when I commited this change, it was only one usage of
svn_ctype out of libsvn_subr module. I was going to deprecated
svn_ctype_table, but this requires function call for each access,
which could decrease performance.
Anyway I didn't see reasons why we cannot leave
svn_xml_is_ascii_xml_name in our public API? We already have function
svn_xml_is_xml_safe().
I don't press for keep it, so revert my commit if you consider.
--
Ivan Zhakov
Re: svn commit: r18932 - trunk/subversion/include
Posted by Julian Foad <ju...@btopenworld.com>.
Malcolm Rowe wrote:
> On Fri, Mar 17, 2006 at 08:32:52PM +0100, Peter N. Lundblad wrote:
Re. svn_xml_is_xml_name():
>>Hmmm, would it be better to document the ASCII part as a @todo or @bug?
>>That would allow us to extend this function to cover the whole Name
>>production when someone gets around to it.
>
> I don't know whether the ASCII part is intended or not - and in any case,
> it would seem a little unreasonable to change the function so drastically.
> Maybe.
>
> The checkin that I did was just a clarification to the docstring zhakov
> introduced in r18202. Ah, I see that Julian originally introduced this
> function in r7528 - maybe he has an opinion as to what the contract
> should actually be, now that the function is public?
1. Re. semantics: For this to be a public API, your new doc string is a good
description of the implementation, and these are acceptable semantics for a
public API, but its name ought to reflect the ASCII aspect of its semantics.
At some later stage we're bound to want an "is_xml_name" with full UTF-8
semantics, and I don't think it's OK to later change the meaning that much.
Therefore let's name it something like "svn_xml_is_ascii_xml_name".
2. Re. r18202: that commit purports to avoid sharing variables
(svn_ctype_table) between libraries:
> ------------------------------------------------------------------------
> r18202 | zhakov | 2006-01-24 14:12:31 +0000 (Tue, 24 Jan 2006) | 13 lines
> Changed paths:
> M /trunk/subversion/include/svn_xml.h
> M /trunk/subversion/libsvn_client/prop_commands.c
> M /trunk/subversion/libsvn_subr/xml.c
>
> Factor out svn_xml_is_xml_name_valid() to eliminate usage of
> svn_ctype_table variable outside of libsvn_subr library. This needed because
> exporting variables from Windows DLLs requires __declspec(dllexport).
> See disscussion here: http://svn.haxx.se/dev/archive-2005-12/0178.shtml
>
> * subversion/include/svn_xml.h
> * subversion/libsvn_subr/xml.c
> (svn_xml_is_xml_name_valid): New function, factored out from
> is_valid_prop_name()
>
> * subversion/libsvn_client/prop_commands.c:
> (is_valid_prop_name): Use new function svn_xml_is_xml_name_valid()
>
> ------------------------------------------------------------------------
> Index: subversion/include/svn_xml.h
> ===================================================================
[...]
> +/** Check whether the UTF8 NAME is a the ASCII subset of an XML "Name".
> + * XML "Name" is defined at http://www.w3.org/TR/REC-xml#sec-common-syn
> + *
> + * @since New in 1.4.
> + */
> +svn_boolean_t svn_xml_is_xml_name_valid (const char *name);
That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
at the time, but did nothing to prevent such use. The email discussion said
that public access to svn_ctype_table[] was to be deprecated, which would
require the svn_ctype_* macros to be converted to functions, but that has not
been done. Now there are other uses outside libsvn_subr, so presumably the
Win32 DLLs again don't build/work properly - is that the case?
I think that commit wasn't a proper way to solve the problem. If we solve the
variable-sharing problem properly, then that commit r18202 can be reverted, and
the problem of how to name and describe the XML-name function goes away. That
would be good because we've no reason to want such a function in our public
API, as far as I know.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r18932 - trunk/subversion/include
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, Mar 17, 2006 at 08:32:52PM +0100, Peter N. Lundblad wrote:
> Hmmm, would it be better to document the ASCII part as a @todo or @bug?
> That would allow us to extend this function to cover the whole Name
> production when someone gets around to it.
>
I don't know whether the ASCII part is intended or not - and in any case,
it would seem a little unreasonable to change the function so drastically.
Maybe.
The checkin that I did was just a clarification to the docstring zhakov
introduced in r18202. Ah, I see that Julian originally introduced this
function in r7528 - maybe he has an opinion as to what the contract
should actually be, now that the function is public?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org