From your questions below, it seems like you need read the HACKING
document. It explains some of the concepts in more detail.
On Wed, 11 May 2005, Madan US wrote:
> On Tue, 2005-05-10 at 06:53, Philip Martin wrote:
> > "Madan US" <email@example.com> writes:
> > That's an ABI change in a public interface so it's not acceptable.
> > You need to retain svn_commit_callback_t and provide a new name,
> > svn_commit_callback2_t say, with the new parameter.
> Whats ABI? I think all functions, pointers that comply to
> svn_commit_callback_t have been touched in this patch. However, I
> understand the client-server version compatibility issue. Is this your
> concern. Could you please explain your concern with an illustration ( a
> scenario ) so that I can make changes with an inherent understanding...
> this would also be a learning for me. Thanks.
ABI means Application Binary INterface. It includes things as function
calling conventions (in what order arguments are put on the stack, where
the return value is placed etc.) and other things that ensures binary
compatibility. When *we* talk about ABI breakage we mean that code linked
to one version of the library will not work with a later version. Adding
(or removing or changing) the arguments to a function is obviously an ABI
change; it will make the program crash or something similar. Changing the
contents of a structure is often an ABI change (some might argue it always
does). Read more about our compatibility rules in HACKING.
> > Unfortunately this looks like it could be quite a big change. You
> > need to keep all the current interfaces that use svn_commit_callback_t
> > and ensure that they continue to work. Then you can provide new
> > versions of those interfaces that support the new callback.\
> Yes, all functions adhering to and using this typedef will be changed,
> but we would be keeping the old versions nevertheless.... that IMHO
> would be inefficient. Pl. comment.
Well, it is not fun, if that's what you're referring to... I've done some
API revving, so I know:-)
But remember that we're a library. Other applications are using our code,
and we can't just force them to upgrade every time we release new stuff.
> > I'm not a DAV/XML expert, can you put arbitrary data there? Do you
> > have to encode it, or escape it?
> > Hmm, a quick experiment shows that the existing hook output appears to
> > get escaped over ra_dav, but not encoded. The hook needs to output
> > UTF-8 if it is to be displayed by the client, otherwise I just see
> > "svn: General svn error from server".
> yes, I missed this point... the output of the post-commit hook should be
> encoded to utf-8. Anyways, I do not know how to do this... will try to
> find out... thanks for that.
More importantly (for the moment) is that it needs to be XML-escpaed, that
means replacing some characters with XML entities (< becomes < and so
on). See apr_xml_quote_string. (See my comment in my response regarding
encodings and invalid XML chars).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 12 10:01:47 2005